ci(kitchen+travis): use bootstrapped amazonlinux-1 images

[myii]

• Automated using feat(vault): use bootstrapped amazonlinux-1 images myii/ssf-formula#94

---

@dafyddj Needed amazonlinux-1 for the epel-formula so took this opportunity to standardise the way bootstrapped images are provided by the ssf-formula. Up to now, it's been using an inline if block solely for the vault-formula; now it can provide amazonlinux-1 to formulas in the same way as pre-salted images.

I've tested all of these across all three suites (and the combined one) here:

• https://travis-ci.org/myii/vault-formula/builds/607049255

[dafyddj]

I'm glad to see the AmazonLinux 1 test platforms filled out with the different Salt releases.
However I do have one comment.

There is a difference between using salt-bootstrap in the provisioner section and adding a provision_command in the driver section.
The latter adds a RUN instruction to the Dockerfile used to create the image, which takes advantage of the Docker layer cache, making subsequent runs very fast.
The former method means that Salt is installed from scratch the first time every instance is created/converged.

The time difference is significant:

# First run `provision_command`
dafydd@meshuga salt-formulas/vault-formula (dev)$ kitchen test amazonlinux$
...
-----> Kitchen is finished. (4m4.93s)

# Subsequent run `provision_command`
dafydd@meshuga salt-formulas/vault-formula (dev)$ kitchen test amazonlinux$
...
-----> Kitchen is finished. (2m40.61s)

# Docker images pruned and removed before following test
# First run `salt_install: bootstrap`
dafydd@meshuga salt-formulas/vault-formula (ci/use-bootstrapped-amazonlinux-1-images)$ kitchen test amazonlinux-1-2019-2-py2
...
-----> Kitchen is finished. (6m46.85s)

# Subsequent run `salt_install: bootstrap`
dafydd@meshuga salt-formulas/vault-formula (ci/use-bootstrapped-amazonlinux-1-images)$ kitchen test amazonlinux-1-2019-2-py2
...
-----> Kitchen is finished. (5m4.35s)

That being said, I don't have a huge preference either way, as I don't see AmazonLinux 1 being heavily used in local development any more (where the time savings would make the most difference), but just wanted to make the point, and leave something to refer to in the future.

So I'm happy to merge it if you still want to.

[myii]

@dafyddj Nope, let's not merge this just yet, after your excellent feedback. That's got me wondering, though: when is the right time to use the provisioner? Surely there must be some reason for having that feature; are you aware of what that might be? As far as I can recall, most/all of the formulas were using this rather than the provision_command, before we started work on all of this standardisation.

[myii]

My initial test related to this PR appear to confirm this.

• https://travis-ci.org/myii/vault-formula/builds/607049255 (slower)
• https://travis-ci.org/myii/vault-formula/builds/607873289 (faster)

[dafyddj]

Surely there must be some reason for having that feature; are you aware of what that might be?

The speed difference is very specific to Docker and the way it builds up an image from cached layers. Another driver such as kitchen-vagrant wouldn't see the speed increase, and so either method could be used, so I think this is just a case of "there's more than one way to do it" - some ways turn out better than others.

Also, the use of pre-Salted images made this issue largely irrelevant.

[myii]

@dafyddj Of course, kitchen-vagrant and other provisioners, thanks for reminding me of that.

I'll make the adjustments in the ssf-formula and then finalise this PR, probably within the next day.

[myii]

@dafyddj I've updated this PR. I've also applied these changes to saltstack-formulas/epel-formula#55. Would you mind merging these?

[myii]

Merging since already confirmed essentially.

[saltstack-formulas-travis]

🎉 This PR is included in version 1.2.3 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀