[ssf] ci(kitchen): avoid using bootstrap for master instances

[myii]

PR progress checklist (to be filled in by reviewers)

• Changes to documentation are appropriate (or tick if not required)
• Changes to tests are appropriate (or tick if not required)
• Reviews completed

---

What type of PR is this?

Primary type

• [build] Changes related to the build system
• [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
• [ci] Changes to the continuous integration configuration
• [feat] A new feature
• [fix] A bug fix
• [perf] A code change that improves performance
• [refactor] A code change that neither fixes a bug nor adds a feature
• [revert] A change used to revert a previous commit
• [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

• [docs] Documentation changes
• [test] Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.

Related issues and/or pull requests

1. Automated using feat(kitchen): avoid using bootstrap for master instances myii/ssf-formula#124
2. https://travis-ci.org/myii/template-formula/builds/645908860 (before)
3. Final Neon Support Fix saltstack/salt-bootstrap#1424 (comment)
4. https://travis-ci.org/myii/template-formula/builds/646343672 (after)
5. feat: update for neon, centos-8 and amazon netmanagers/salt-image-builder#21

Describe the changes you're proposing

There have been a number of changes to the salt-bootstrap recently in preparation for Neon. One of the side-effects is that attempting to bootstrap the pre-salted master images is resulting in failure [2]. The explanation of this is available in that PR's discussion [3]. This PR addresses that by removing the bootstrap for the master images [4] and for this to be spread through the 60+ formulas that are currently managed [1]. This is need ASAP, since all of our master instances will be failing until this is propagated. Not using the bootstrap isn't really that bad since our pre-salted images are automatically rebuilt every 7 days so it will never be that far behind. Besides, it will also make our Travis runs a touch quicker, since it won't be bootstrapping on top of the pre-salted image.

The actual pre-salted images have been through some changes as well recently [5]. I've taken the opportunity to update the amazonlinux instances at the same time, since we were still using develop, which was bootstrapped to master. We're now able to use master directly, as well as the py3 instances.

Pillar / config required to test the proposed changes

As-is.

Debug log showing how the proposed changes work

As shown in Travis.

Documentation checklist

• Updated the README (e.g. Available states).
• Updated pillar.example.

Testing checklist

• Included in Kitchen (i.e. under state_top).
• Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
• Updated the relevant test pillar.

Additional context

[baby-gnu]

I find it perfectly fine to avoid doing a bootstrap each time. I see no problem by having images at most 1 week behind salt master branch.

Regards.

[myii]

@javierbertoli @baby-gnu Thanks for the reviews and merge.

[saltstack-formulas-travis]

🎉 This PR is included in version 4.0.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀