> Le 24 août 2015 à 21:59, Christopher Wood <christopher_w...@pobox.com> a > écrit : > > I am not seeing a large amount of blog entries complaining about this > upgrade, how has that gone for you? Is there anything you found particularly > painful? Would you have done anything different in retrospect? > > I'm staring down a 3.7.2 -> 4.2.1 upgrade and after reading a number of docs > the back-of-the-envelope optimal upgrade path is as follows. If any of you > have commentary I am quite interested, otherwise I will try it and see what > happens. I feel like this might be more time-consuming work but less > brainpower effort than just yanking everything to 4.2. > > 1) rpms up to puppet 3.8 > > PostgreSQL 8.4 to 9.4 > PuppetDB 2.2.2 to 2.3.7 > (puppetdb-terminus from 2.2.2 to 2.3.7) > Puppet 3.7.2 to 3.8.2 > > 2) enable the future parser > > 3) replace puppet 3.8.2, passenger 5 with puppetserver 1.1.1 > > 4) replace puppetserver 1.1.1 with puppetserver 2.1.1 > > 5) upgrade PuppetDB from 2.3.7 to 3.0.2 > > 6) use the puppetlabs-puppet_agent forge module to upgrade agents to 4.2.1 > >
My biggest problem: there isn't any working dashboard working with Puppet 4. The puppetdb APIv4 in puppet db 3.1 is not the same as the APIv4 in puppetdb 2, so all of them are now broken, even the one that thought they uses the v4 API. I had a lot of trouble with facter, it's rewritten but not tested on older release, a few things were broken on Redhat 5 : https://tickets.puppetlabs.com/browse/FACT-1152 https://tickets.puppetlabs.com/browse/FACT-1137 If you use mcollective there is a bug that prevent installation of both mcollective and puppet on the same server on Redhat 6 : https://tickets.puppetlabs.com/browse/PUP-4970 and no one take care for this bug at puppetlabs. All the path change /etc/puppet, /usr/bin to /etc/puppetlab, /opt/puppetlabs. Minor problems might arise from that, if you don't prepare that on puppet modules, other management scripts. I hade no problem with embedded PKI, rsync -av /var/lib/puppet/ssl /etc/puppetlabs/puppet/ is enough to keep it. Check your: [master] certname =... in puppet.conf. Rules changes slightly and I had problem with that. If you wrote you own modules, expect a lot of warning and broken modules becase of new variable typing. Once the new server was up and running, I used this simple script on all the nodes: [ -x /opt/puppetlabs/bin/puppet ] || (\ [ -x $(type -p facter) ] && \ rpm -e puppetlabs-release && \ rpm -Uvh http://.../puppetlabs/$(facter operatingsystemmajrelease)/PC1/x86_64/puppetlabs-release-pc1-0.9.2-1.el$(facter operatingsystemmajrelease).noarch.rpm && \ yum install -y puppet-agent && \ rsync -av /var/lib/puppet/ssl /etc/puppetlabs/puppet/ && \ /opt/puppetlabs/bin/puppet agent -v --onetime --no-daemonize --no-show_diff --pluginsource puppet:///plugins --use_srv_records && \ service mcollective restart -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/88164374-6100-425D-B7D1-C4C944B35642%40orange.fr. For more options, visit https://groups.google.com/d/optout.
