Tails

#1 Updated by intrigeri 2016-09-24 04:44:22

• blocked by Feature #11833: Make our Puppet code compatible with the "future" parser added

#2 Updated by intrigeri 2016-09-24 04:44:32

• blocked by Feature #11835: Upgrade Puppet master and clients to 3.8 added

#3 Updated by intrigeri 2016-09-24 04:45:03

• related to Bug #11543: bitcoin.lizard cannot connect to our Puppet master added

#4 Updated by intrigeri 2016-09-24 04:46:33

• blocks deleted (Feature #11833: Make our Puppet code compatible with the "future" parser)

#5 Updated by intrigeri 2016-09-24 04:46:57

• blocks deleted (Feature #11835: Upgrade Puppet master and clients to 3.8)

#6 Updated by intrigeri 2016-09-24 04:56:44

• Description updated

#7 Updated by intrigeri 2017-04-09 11:03:23

• Assignee set to intrigeri

#8 Updated by intrigeri 2017-04-11 16:09:44

• Description updated

#9 Updated by intrigeri 2017-06-05 13:39:21

• Target version set to Tails_3.5

#10 Updated by intrigeri 2017-06-30 11:21:37

• blocked by Feature #13284: Core work: Sysadmin (Adapt our infrastructure) added

#11 Updated by intrigeri 2017-06-30 11:22:04

• blocks deleted (Feature #13284: Core work: Sysadmin (Adapt our infrastructure))

#12 Updated by intrigeri 2017-06-30 11:22:13

• blocks Feature #13284: Core work: Sysadmin (Adapt our infrastructure) added

#13 Updated by intrigeri 2017-08-13 14:11:18

• Description updated

PuppetDB is now in Debian :)

#14 Updated by intrigeri 2017-08-13 14:12:02

• Description updated

#17 Updated by intrigeri 2018-01-09 22:56:11

• 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 Feature #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):

1. Install PuppetDB locally and see how some of the exported resources we use work with it.
2. Handle Feature #11833, for which I now have a plan (I’ve realized there’s a small chance it magically fixes Feature #11836).
3. Deal with Feature #11836, somehow (possibly while doing the next step).
4. 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.
5. 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).
6. 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 :)

#18 Updated by intrigeri 2018-01-09 22:58:38

• Target version changed from Tails_3.5 to Tails_3.7

#21 Updated by intrigeri 2018-04-08 10:02:24

• Assignee changed from intrigeri to groente
• QA Check set to Ready for QA

(All subtasks are now Ready for QA :)

#23 Updated by groente 2018-05-02 16:41:35

• Status changed from In Progress to Resolved
• QA Check changed from Ready for QA to Pass

\o/

#24 Updated by intrigeri 2018-06-11 06:55:59

• related to Bug #15647: PuppetDB is broken since 2018-06-10 added

#25 Updated by groente 2018-06-12 07:02:25

• related to Bug #15650: libtools-nrepl-clojure updates kept back on puppet-git added

#26 Updated by intrigeri 2018-10-31 08:18:24

• related to Bug #16083: APT snapshot used for libjetty9 is unreliable added

#27 Updated by intrigeri 2018-12-29 11:13:40

• blocks Bug #13285: Migrate to upstream Puppet Icinga2 module added