chronos marathon addon

[ryane]

converts chronos to an addon that runs in marathon

Fixes #792
Fixes #1155
Obsoletes #1168

• Installs cleanly on a fresh build of most recent master branch
• Upgrades cleanly from the most recent release
• Updates documentation relevant to the changes
• Rebases cleanly onto the latest master

[langston-barrett]

How will people upgrade from Mantl 1.0?

[ryane]

good question. If you already have a 1.0 cluster with chronos installed, I don't know if there is really a great reason to switch. But, I can add a little bit to the documentation that explains how to turn off the existing chronos on control nodes and switch to the version running in marathon

[ryane]

ah but since we are using the same role name, it is likely that the addon will be installed anyway if someone has chronos in their mantl.yml and reprovisions. I'll have to add something to check for that.

[langston-barrett]

@ryane We could move it to addons/roles/chronos (with the changes in #1224), and keep the old role (with a deprecation warning) for a release or two.

Other than that, this is looking awesome! I got a successful install with no Chronos dashboard in MantlUI for Chronos, and the UI appears and works after the Marathon deployment finishes.

[langston-barrett]

Deleting the Marathon task also works as described.

[ryane]

@siddharthist I added a check to make sure it already isn't installed in the playbook and I added some docs. I didn't resurrect the old role b/c I wasn't sure how it would behave if we had a chronos role in both roles and addons/roles. we can move this to addons/roles in #1224 since that branch needs rebased anyway and it already includes the change to ansible.cfg

[langston-barrett]

@ryane Sweet, I'll deploy this again later today to make sure it's working as expected with the new changes.

[langston-barrett]

Successfully skips when Chronos is installed on a 1.0 cluster! Unfortunately, the instructions won't reinstall Chronos, because mantl-api is the version that doesn't watch the Consul K/V to install packages.

I'm testing whether or not this is fixed by running sample.yml and then chronos.yml.

[langston-barrett]

If you just run sample.yml first, installing Chronos works after that. If we add that to the docs, I'll merge this.

[langston-barrett]

This has now been tested on its own, as well as with a sucessful upgrade from 1.0. Merging

[ryane]

I didn't use fail b/c I was thinking of the scenario where you have a 1.0.3 cluster with chronos in your mantl.yml. Then, you pull 1.1, and re-provision with the same mantl.yml. I didn't want the provisioning to fail at that point.

[ryane]

When you upgrade from a 1.0.x cluster to 1.1, and you re-run your sample|mantl playbook, it should actually upgrade mantl-api.