Chapi requires both marathon and chronos configs to be present

[ppar]

Chapi assumes that the configuration always contains both a marathon and a chronos service. This causes at least two problems in practice:

• It's impossible to set up chapi in an environment where you only have one but not the other

• Even in an environment where both frameworks are used, you may have situations where you'd want to only address one of them. Chapi doesn't provide any command line arguments to select just one.

Setting the config variables to null like README.md suggests worked at some point but doesn't anymore.

I would generalize the configuration mechanism a bit to overcome these problems.

Example configuration:

profiles:
  # Profile for addressing marathon only
  acme-prod-marathon:
    services:
      - framework: marathon
        url: http://marathon.acme.com:8080/
        http_username: acme
        http_password: acme123
        repository_dir: "/Users/jsmith/src/marathon-jobs"
        
  # Profile for addressing chronos only
  acme-prod-chronos:
    services:
      - framework: chronos-2.0
        url: http://chronos.acme.com:4400/
        http_username: acme
        http_password: acme123
        repository_dir: "/Users/jsmith/src/chronos-jobs"

  # Profile for addressing both simultaneusly
  acme-prod:
    services:
      - framework: marathon
        url: http://marathon.acme.com:8080/
        http_username: acme
        http_password: acme123
        repository_dir: "/Users/jsmith/src/marathon-jobs"
      - framework: chronos-2.0
        url: http://chronos.acme.com:4400/
        http_username: acme
        http_password: acme123
        repository_dir: "/Users/jsmith/src/chronos-jobs"

  # For ease of maintenance, a simple include mechanism could 
  # make the above definition shorter:
  acme-prod:
    services:
      - include: acme-prod-chronos
      - include: acme-prod-marathon

  # With the assumption gone that there are always exactly one marathon
  # and chronos service, we could support a fictional use case like:
  acme-farm:
    services:
      - framework: marathon
        url: http://marathon-ber.acme.com:8080/
        http_username: acme
        http_password: acme123
        repository_dir: "/Users/jsmith/src/marathon-jobs"
        ignore:
          - "!*-ber"
      - framework: marathon
        url: http://marathon-lon.acme.com:8080/
        http_username: acme
        http_password: acme123
        repository_dir: "/Users/jsmith/src/marathon-jobs"
        ignore:
          - "!*-lon"
      - framework: marathon
        url: http://marathon-nyc.acme.com:8080/
        http_username: acme
        http_password: acme123
        repository_dir: "/Users/jsmith/src/marathon-jobs"
        ignore:
          - "!*-nyc"

With this pattern, you could simply pass a profile name on the command line to select the environment(s) you want chapi to target.

Also it would be possible to add support for other mesos frameworks (or multiple flavors / versions of current the frameworks), hence "chronos-2.0" in the example. ("Framework" might not be the best wording for this though, since its's a Mesos-specific term, unless we intend chapi to manage Mesos-based services only)