Puppet 3 to 4 Upgrade - Foreman with Separate CA

Hey Guys,

I'm starting (way too late - I know) our Puppet 3 to 4 migration, (on foreman 1.14.3 currently) and I have some question(s) I'm hoping someone can provide me some insight with!

Multiple Puppet Masters:
We have multiple puppet-masters - I'm assuming I can take "some of them" and do the upgrade - test/verify, and reintroduce them into the load-balancer, and let them run side-by-side with puppet 3.X masters, until I roll through and upgrade all of them. Going through the instructions (both foreman and puppet) I see the steps to ensure a puppet 4.X master can communicate with a 3.x agent - so I see nothing immediately evident that would mean this wouldn't work? Hoping this is possible in lieu of an "all or nothing" type buildout or cutover.

Puppet with External CA Server
The documentation points to puppet 4.x masters needing a special switch to "disable" the CA portion if you use an external CA server, and that's easy enough. We have our CA separate from our puppet masters entirely (the only smart-proxy role on that server is the CA - not even a puppet master at all). Based on what I'm reading - I need to upgrade my puppet-masters, set that setting, and then do "nothing" on my CA server, as it isn't also a puppet master. Is this correct? Just want to make sure there isn't any Smart-Proxy CA config changes between Puppet 3 and puppet 4?

Foreman-Specific "puppetserver" performance tweaks
I remember when tweaking Passenger, I kept running into settings either not available in the open-source version (puppet enterprise only settings) or settings not available in open-source Foreman (RedHat Satellite specific tweaking guides). I was able to eventually sort through it all and get settings that worked - but does anyone have or know of any guides centered around Open-Source Foreman (not Satellite) and Open Source Puppet (Not Puppet Enterprise) regarding puppetserver performance tuning? Not having to sift the whole beach for the few gold nuggets would be amazing!

Of course - I have a test environment I'll be doing this on first, but hoping the hive mind has some insight, guidance, or advice here :slight_smile:

~Jason Lang

The information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.

Hi Jason,

I am in the process of doing this from CentOS 6.x, Foreman 1.12.3 with
Puppet 3.x.

I don't have all your details but I am working on a life cycle upgrade at
the moment.

I suggest:

  1. Upgrade Foreman servers to 1.12.4.

  2. Build a new Foreman all-in-one (but without a CA or DB.) You can point
    it to your existing CA and common Foreman DB. In my case I am building a
    new CA. But I am using the existing Foreman DB.

  3. I am using CentOS 7.3, Foreman 1.12.4, with Puppet 4.10.x.

  4. With this default build I have found that Puppet 3.x clients/agents can
    report to Puppet 4.x servers.

Note the Puppet 4. Server does not use Passenger!

I am still testing but on my test laptop I have:

CentOS 6.x MySQL server, Puppet 3.8.7 (client only)

CentOS 6.x Foreman 1.12.4 Puppet 3.8.7 - pointing to the above MySQL server.

I then added:

CentOS 7.3 Foreman 1.12.4 Puppet 4.x - pointing to the above MySQL server.

A second CentOS 7.3 Foreman 1.12.4 Puppet 4.x - pointing to the above MySQL
server. I then updated Puppet to 5.0

Just a few notes in the hope that they can help.

Regards, Mike.

··· On Sunday, September 10, 2017 at 10:32:45 AM UTC-4, Lang, Jason wrote: > > Hey Guys, > > > > I’m starting (way too late – I know) our Puppet 3 to 4 migration, (on > foreman 1.14.3 currently) and I have some question(s) I’m hoping someone > can provide me some insight with! > > > > Multiple Puppet Masters: > > We have multiple puppet-masters – I’m assuming I can take “some of them” > and do the upgrade – test/verify, and reintroduce them into the > load-balancer, and let them run side-by-side with puppet 3.X masters, until > I roll through and upgrade all of them. Going through the instructions > (both foreman and puppet) I see the steps to ensure a puppet 4.X master can > communicate with a 3.x agent – so I see nothing immediately evident that > would mean this wouldn’t work? Hoping this is possible in lieu of an “all > or nothing” type buildout or cutover. > > > > Puppet with External CA Server > > The documentation points to puppet 4.x masters needing a special switch to > “disable” the CA portion if you use an external CA server, and that’s easy > enough. We have our CA separate from our puppet masters entirely (the only > smart-proxy role on that server is the CA – not even a puppet master at > all). Based on what I’m reading – I need to upgrade my puppet-masters, set > that setting, and then do “nothing” on my CA server, as it isn’t also a > puppet master. Is this correct? Just want to make sure there isn’t any > Smart-Proxy CA config changes between Puppet 3 and puppet 4? > > > > Foreman-Specific “puppetserver” performance tweaks > > I remember when tweaking Passenger, I kept running into settings either > not available in the open-source version (puppet enterprise only settings) > or settings not available in open-source Foreman (RedHat Satellite specific > tweaking guides). I was able to eventually sort through it all and get > settings that worked – but does anyone have or know of any guides centered > around Open-Source Foreman (not Satellite) and Open Source Puppet (Not > Puppet Enterprise) regarding puppetserver performance tuning? Not having to > sift the whole beach for the few gold nuggets would be amazing! > > > > Of course – I have a test environment I’ll be doing this on first, but > hoping the hive mind has some insight, guidance, or advice here J > > > > ~Jason Lang > > The information contained in this message may be privileged, confidential > and protected from disclosure. If the reader of this message is not the > intended recipient, or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any > dissemination, distribution or copying of this communication is strictly > prohibited. If you have received this communication in error, please notify > your representative immediately and delete this message from your computer. > Thank you. >