Last week, I gave a talk at PuppetConf 2016, “Enjoying the Journey from Puppet 3.x to 4.x,” and received some great feedback. One of the major points is that you wanted to hear more opinionated viewpoints than “it depends,” even when it depends! It can be difficult to fit that into a 45 minute talk – heck, I had a 45 minute talk at the airport about just one slide! – but thankfully, I have a blog where I can keep writing and no-one can stop me. Let’s take a look at my slides and go through some of the “it depends” points with some more strongly worded opinions.

Roadmap (slide 8):

• DO turn on Future Parser at 3.8.6
• DO turn on Strict Variables. You should do this at 3.8.6 if possible; otherwise wait until you get to 4.latest and then turn it on.

Validate / Create Tests (slide 11):

• You MUST have unit tests with rspec-puppet.
• You SHOULD have coverage of all manifests, facts, types, providers, etc. If you do not, put it in your task list to improve coverage. Hint: this should always be in your task list, you’ll never have 100% coverage!
• You SHOULD NOT let lack of acceptance/integration tests hold back your upgrade. Add acceptance/integration tests if you understand how to perform those tests. If you do not, put it in your task list to learn about acceptance/integration tests and how they apply to your apps and infrastructure.
• DO pin to the same versions of modules as specified in your Puppetfile, specifically referencing the module on the forge rather than pointing to HEAD on git.
• I have no opinions on catalog diffs 🙂

Upgrading the Master (slides 16-18):

• Treat the master as a service – as long as agents can check in, puppetdb reports can be filed, etc., this is met. Do not treat the master as a server you log into and care about deeply. It’s perfectly fine to upgrade a master running EL6 in-place, since you’re not actually using the system ruby or whatnot (keep it patched, though!).
• DO perform in-place upgrades when the master’s OS is still supported by the vendor and your internal IT.
• DO perform new deployments when the master’s OS is NOT supported by the vendor and your internal IT.
• DO perform new deployments when you use an Immutable Infrastructure pattern.
• DO migrate the CA when you either A) have a majority of the 5 year expiration time left on the CA expiration or B) have a fleet large enough that re-issuing certs for all nodes would delay the migration unacceptably.

Upgrade the Agents (slide 20):

• 3.x: SKIP the upgrades until you reach FOSS 3.8.7 / PE 3.8.6.
• 4.x: Go straight from 3.8.x to FOSS 4.latest (4.7.0) / PE 2015.3.3. With PE, perform another upgrade to 2016.4.0.
• DO use a module to perform this. jlambert121/puppet is great for FOSS only, puppetlabs/puppet_agent works well with both PE and FOSS.
  • More detail on using puppet_agent with PE.

Relax and Enjoy (slide 21):

• Laphroig 😉

I hope this helps anyone planning out their upgrade. If you have any questions about your setup, drop a comment or tweet at me. Enjoy!