New distributive packages

[langston-barrett]

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

Upgrade to new packaging system, which will make fixing broken checks a vastly faster process.
Removes duplicated code from back when I didn't know how to Ansible.
Fixes #1259

The dnsmasq checks are failing on this because of #1265

[langston-barrett]

This will be ready as soon as mantl/mantl-packaging#56 is merged. This has been tested on DO, Vagrant.

[ryane]

it looks like mantl/mantl-packaging#56 has been merged but I'm still seeing broken distributive checks (upgrade from 1.0.3 on aws):

time="2016-03-15T14:21:28Z" level=info msg="Report from checklist" checklist="dnsmasq health check" report="↴\nTotal: 8\nPassed: 7\nFailed: 1\nOther: 0\nIs not a file: /etc/resolv.conf" 

[langston-barrett]

@ryane The CI build is broken on mantl-packaging, and so didn't publish the new version of that RPM. I'll do so manually soon.

[langston-barrett]

Actually, it looks like it has been uploaded. I'll do some digging soon.

[ryane]

@siddharthist I just revisited this. I noticed a couple of things. First, the distributive package itself is not being upgraded. After applying this pr on 1.0.3, I end up with:

distributive.x86_64 0.2.4-1

On a fresh build, I end up with:

distributive.x86_64 0.2.5-1

Also, all of the distributive* files in /etc/consul are still present post-upgrade so that also generates a bunch of failed checks.

[langston-barrett]

@ryane Thanks for checking, I think that change should fix the issue with the distributive package being upgraded. As for deregistering checks, do you have any suggestions? We could just make an upgrade ansible playbook, but that's kinda messy.

[ryane]

if we do latest, though, aren't we opening ourselves up for problems down the road if we release a new version of distributive that is incompatible with this release? this is what happened with mantl-dns in #1265. Can we just explicitly tell it to install 0.2.5-1?

[langston-barrett]

We were having that discussion in Slack the other day. That's my preferred option, I'll make it so.

[ryane]

yeah, it is messy. we do already have a precedent of upgrade logic in playbooks: https://github.com/CiscoCloud/mantl/blob/master/roles/zookeeper/tasks/main.yml#L33. It's not ideal but not sure how to get around it in this case.

[langston-barrett]

All the versions are now pinned to avoid pain later. I'll work on an upgrade playbook.

[ryane]

super minor but it is actually needed for upgrading mantl 1.0.x to 1.1

[ryane]

@siddharthist do you think we should merge this as-is and then create a new issue to track the upgrade to 1.1? It would be good to get master fixed

[ryane]

this fixes new builds but upgrades are still a problem. tracking in #1288