Fix distributive upgrade from Mantl 1.0.3 -> 1.1

[langston-barrett]

Waiting on mantl/mantl-packaging#67

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

Tested on AWS

[ryane]

I'm just wondering if this is the best place for this. A fresh install failed for me b/c I hadn't update my local mantl.yml with this task from sample.yml. I'm not sure how widespread of an issue this will be since it won't affect new users but it might bite more of us who have existing Mantl configs. And, in general, keeping the sample.yml as simple as possible seems like a good thing. Do you think it might be cleaner to just put this in a tiny role that is included as a dependency in common?

[langston-barrett]

I'm glad to get feedback on this, since I wasn't really sure where to put it. I don't have any kind of a preference. I think that we should be able to expect that folks will update their mantl.yml with new stuff in sample.yml every release (thinking about past releases when we have added/removed roles, etc.), but I'm also just generally unsure of where this belongs.

I like the idea of using Ansible role dependencies more throughout our project so we don't have to depend on, say, the ordering of tasks in sample.yml. If we create a new role, maybe we can add it as a dependency for any role that uses our repos.

[BrianHicks]

I don't think this belongs in the playbook. We should include roles and depend on them, sure, but this pins us to supporting this for longer than in a role. (Because it's encouraged to update your sample.yml with customizations.)

Maybe this should be a "repos" role that common et al. depend on.

[ryane]

+1, I think this will be a little cleaner. @siddharthist do you mind moving this to a "repos" role?

[langston-barrett]

Not at all, will do ASAP.

[ryane]

Successful upgrade from 1.0.3! Just had one question about the sample.yml.

[langston-barrett]

@ryane @BrianHicks Done, tested upgrade from 1.0.3 -> 1.1 on AWS. Travis will check fresh install.

[langston-barrett]

I'm a little confused, Travis is failing on a task (common | enable yum repos) that isn't present in this branch. I'm going to rebase and try again.

$ git status                      
On branch fix/distributive-upgrade
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   plugins/inventory/terraform.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    aws.tf

no changes added to commit (use "git add" and/or "git commit -a")
$ grep -ri 'enable yum repos' roles/common
$

[langston-barrett]

Well, after rebasing I found the problem, but Travis isn't testing. I'll rebase again, I suppose.

[ryane]

is this ready for a manual test? it looks like the aws build failed due to a transient network error but the other two builds completed successfully.

[langston-barrett]

@ryane Yes, it's ready for manual testing. Just an upgrade from 1.0.3 -> master on another cloud would be perfect.

[ryane]

cool, I'll kick of an upgrade on gce

[ryane]

successful upgrade from 1.0.3 on GCE