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)
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
nulllike 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:
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)