Puppet upgrade options?

[opethdisciple]

Hoping there is some of you who have experience with Puppet for host configuration.

Currently we are on a very old version 3.4.2 and looking to upgrade.

The plan was to upgrade to 3.8.7 as that the last version of 3.x available which would mean our existing code wouldn't need too much refractoring.

However things are very complicated with the deployment so far. Believe it or not they use Puppet to create Puppet Masters. I've tried deploying a new Puppet master using the existing module and then upgrading the components one buy one to get up to Puppet 3.8.7 and the applicable version of Facter and Hiera. Except this is proving very complex.

Also because the version we are running and want to upgrade too is very old the documentation we want isn't out there.

So we are thinking of maybe going to a slightly newer version which would mean there should be more guides and documentation out there but with the disadvantage that it will break more thing in the puppet modules.

How would you go about tackling this issue? What version of Puppet would you aim to deploy?

Thanks

 

[droyden]

How is it currently packaged and what OS?
Is it the enterprise or free version?

I have just migrated from 3.8.x to v5, on RHEL (5,6,7). Mine is the free version, installed via rpm. I upgraded the master to the latest version of 3 (3.8.7) and then upgraded all agents.

Built a new puppet 5 master with activemq etc and migrated each node (via a staggered automated approach).

 

[opethdisciple]

How is it currently packaged and what OS?
Is it the enterprise or free version?

I have just migrated from 3.8.x to v5, on RHEL (5,6,7). Mine is the free version, installed via rpm. I upgraded the master to the latest version of 3 (3.8.7) and then upgraded all agents.

Built a new puppet 5 master with activemq etc and migrated each node (via a staggered automated approach).

Free version.

Interesting you took the approach of going 3.8 and then 5. How did you find the jump from 3.8 to 5? Did you have to refactor a lot of your modules?

Why did you not go for 6 instead of 5?

Also I've just seen today that Puppet offer the puppetmaster as a docker container. I might* try and play with that.

We are having major issues at the moment trying to get to 3.8.7. We have a script that someone put together to deploy in our environment using 3.4.2 we've followed it and deployed 3.8.7.

At the moment clients can compile their manifests but we are getting 403 errors on a host of files and directories. So we are at a lose.

I came across a Google message board today discussion upgrading Puppet. One of the things I read was people where saying trying to go 3 -> 4 -> 5 -> 6 is actually a lot more work as with every jump you spend time fixing things that they might of changed again when you go up a version.

So maybe your approach of 3.8 -> 5 is a good approach. At the end of the day Puppet 5 is fairly modern. But I'm curious why you didn't go for 6 instead?

Also why activemq?

 

[droyden]

With regards to the 403 make sure the puppet user can read the files or you have the option within the puppet.conf (or auth.conf?) to not use filesystem permissions.

3.8 to 5 didn't require too much work, but read the docs for deprecated / removed settings. If you have stringify turned on already that should mean you are in a good place. 5 is a bit more strict so will likely flush out any bad manifests. You can use puppet-lint on v3 to check for syntax.

The main consideration I had was number comparison, it needs to be

$bar == '6'

Instead of $bar == 6

(either will work on 3), the second won't alert but will not evaluate as you expect.

I think I decided on 5 as there were even more items removed / deprecated in 6 that would have required additional rework.

If you use hiera, the format in 5 supports the new look-up method but also the 3 style, I don't think 6 does. Note that the layout of the file changed.

I use activemq for mcollective, for no reason than we used it for v3

If the master is a virtual machine I would clone it and isolate for easy test upgrading (if it's physical I would p2v).

 

[opethdisciple]

@droyden

Did you have any issues with SELinux?

Solved the 403 errors but still have SELinux issues with version 3.8.7 Puppet.

We have a script that was written around the time RHEL was at version 6.4.

The script involves building custom SELinux modules. We've done that but still with SELinux turned on have issues. I'm wondering if some of the contexts that the custom modules are setting are not correct or applicable anymore.

Quite hard to diagnose as there doesn't seem too much info on line about what the correct contexts should be.

I've tried the setroubleshoot tool to diagnose the AVC errors but not getting far.

 

[droyden]

Nope afraid not, we disable selinux across the board.

 

[opethdisciple]

Nope afraid not, we disable selinux across the board.

We often go to Red Hat offices for tech talks and they hand out SE Linux colouring books to drum the message in that SELinux is child's play.