Migrate our infrastructure to Puppet 4
On Stretch we won't have Puppet 3, so we'll have to migrate to Puppet 4.
Lots of interesting discussions on this topic have happened on https://bugs.debian.org/826551, including how to migrate an existing storedconfig database to PuppetDB. Since then, puppetdb made it into Debian.
See upstream's upgrading checklist for details.
#17 Updated by intrigeri about 1 month ago
- Status changed from Confirmed to In Progress
As said elsewhere last week, during the 3.5 cycle I want to plan this migration. Here's what I did in order to get a clearer idea of what this project will involve:
- Started a discussion with the shared Puppet modules group to learn how others are handling this. Jérôme's first answer is inspiring:
- He went ahead and "dumped a number of shared modules in favor of modules maintained by other people", which is consistent with the long-term plan of this group. I think we should do the same when feasible, instead of investing time to port these poorly maintained modules to Puppet 4: moving to modules maintained by big players in the Puppet community (puppetlabs, voxpopuli, camptocamp) might require a bigger initial investment, but it's clear it'll pay off on the long term. I'll decide on a case by case basis.
- He's running PuppetDB from sid on Stretch (and apparently Micah does the same). Good news, this gives us a workable solution while I was really wondering what kind of ugly trade-off we would have to make :) I'll try this.
- Migrated my own laptop (that runs sid) to Puppet 4. This machine runs a subset of the modules we use on our infra, so:
- This gave me an idea of how much work is required to port code to Puppet 4. tl;dr: not that much in general, it's mostly mechanical once one has understood the differences; but when the code is really old school it sometimes requires quite involved refactoring, which is a bit scary without a good test suite.
- I've updated all the Puppet code I use to make it work with Puppet 4 (i.e. basically #11833), which resulted in submiting at a bunch of merge requests against some of the aforementioned shared Puppet modules. groente, if you want to come back to it when you have time, in order to learn by reviewing, this first batch is: https://gitlab.com/shared-puppet-modules-group/postfix/merge_requests/20, https://gitlab.com/shared-puppet-modules-group/postfix/merge_requests/18, https://gitlab.com/shared-puppet-modules-group/puppet/merge_requests/10, https://gitlab.com/shared-puppet-modules-group/shorewall/merge_requests/11 and https://gitlab.com/shared-puppet-modules-group/postfix/merge_requests/19. There will be more as I move forward with the next steps.
Next steps are (note to myself but also so that you folks can follow along):
- Install PuppetDB locally and see how some of the exported resources we use work with it.
- Handle #11833, for which I now have a plan (I've realized there's a small chance it magically fixes #11836).
- Deal with #11836, somehow (possibly while doing the next step).
- Set up a Puppet 4 master + PuppetDB on our production infra, feed it with our manifests + modules (using a different branch on the manifests repo, so I can point to new versions of submodules that are compatible with Puppet 4), make it manage a few non-critical systems that don't export resources used by other systems (most likely something on sib), fix problems.
- Press the big red button i.e. make the Puppet 4 master manage all our systems: migrating them one after the other would be ideal, but due to our heavy reliance on exported resources, I think there will need to be a few flag days — best case — or a single one — worst case).
- Upgrade all Puppet agents to Puppet 4.
Regarding planning, I'll probably focus on this next week but then my schedule is quite packed already in 2018Q1. Still, I think there's actually a chance that I get this done by the end of March, we'll see. In any case, I'll take note of everything that would be worth reviewing by groente, as part of his Puppet training, like I started to do above :)
As said elsewhere last week, during the 3.5 cycle I want to plan this migration.
Regarding planning, I'll probably focus on this next week
but then my schedule is quite packed already in 2018Q1. Still, I think there's actually a chance that I get this done by the end of March, we'll see.
I don't think that'll be done in 2018Q1. 2018Q2 seems more realistic.