This message was deleted.

https://puppet.com/docs/pe/2021.7/upgrading_pe.html#upgrading_pe There's some warnings about disk space due to the postgres upgrade and warnings about agent support that's been dropped but I know customers have gone through the upgrade and it works fine. Making sure https://forge.puppet.com/modules/puppetlabs/pe_status_check checks are clean really helps. If you use PEADM you can use https://github.com/puppetlabs/puppetlabs-peadm/blob/main/plans/upgrade.pp to make it even easier and a lot of customers are taking that on now. PEADM has a convert https://github.com/puppetlabs/puppetlabs-peadm/blob/main/plans/convert.pp to take on non-PEADM managed infrastructures too,

If upgrading: check if the underlying OS/Version is still supported.

110% of the current PostgreSQL 11 datastore

which version of 2019.x. as there is a psql migration on one of those (automatic but its a consideration), but yes, we use the installer all the time and its a perfectly good and supported way of upgrading PE

now if PE would support different major OSes for the PE infra, we could upgrade the whole env without downtime 😞

would need to loop in a dev, but i believe its just about the limitation of package distribution, the EL installer only has EL packages etc, and therefore only serves EL packages and only expects EL packages

It would really help for cluster upgrades if we could have multiple compiler with same PE version but different OS

I think @csharpsteen had looked at this a bit to see the technical side

It would mean installing large infrastructures with multiple OS’s would require either the installer to be larger, to distribute all the variations, or a pre install staging step

why does the installer need the packages? I can bootstrap a compiler from packages on the primary. and our primary already has the different pe_repo classes for different OSes. because we already mix agent OSes

pe_repo doesnt have other versions of puppetdb, puppetserver etc

ahh. only the agents?

yep

damn

to account for universtal offline install, you would need to build a customm installer with all debian / el variants

I wouldn't mind that

there is tooling built in https://puppet.com/docs/pe/2019.8/backing_up_and_restoring_pe.html

Also some not quite ready yet private plans backup and restore on peadm which would show how some of the data can be backed up/restored too. Like Classification via the API https://github.com/puppetlabs/puppetlabs-peadm/blob/main/plans/backup.pp https://github.com/puppetlabs/puppetlabs-peadm/blob/main/plans/restore.pp

and that works across major PE versions?

the standard process is for migrating horisontally

okay. So I would to PE 2019-2021 inplace upgrade, then take a backup, reinstall OS from RHEL 7->8, restore PE backup?

oh id need to check but i dont think you can to a major version OS upgrade on PE

mhm

The CA is fine to manually jump over, and i think you would get away with a classification dump

Just chiming in to back up Marty. Marty is correct that you can’t do a major OS upgrade under PE. You’ll need to treat it like a fresh install. There is a note about major OS upgrades here (and also on the supported OS page). @bastelfreak What you said makes sense: Upgrade from 2019 > 2021 while on RHEL 7, then use backup & restore to go to RHEL 8. Alternately, you could do the backup & restore to RHEL 8 first, then handle your upgrade to 2021, since both 2019 and 2021 support RHEL 7 and 8 for primary. One caveat to note: At this time, the built-in backup and restore function is “cleanest” for standard installations without disaster recovery. There are some notes about the limitations at the top of this page.

thanks for the feedback!