On Fri, Mar 12, 2010 at 4:16 PM, Dennis J. <[email protected]> wrote: > On 03/12/2010 11:37 PM, Stephen John Smoogen wrote: >> >> On Fri, Mar 12, 2010 at 2:47 PM, Dennis J.<[email protected]> wrote: >>> >>> Hi, >>> I just installed a new machine in our infrastructure but I can't get the >>> puppet package to work. I see it has recently been updated to 0.25.4 >>> while >>> the previous version i EPEL was 0.24.8. The other machines that are still >>> running 0.24.8 are all doing fine but on the one with the new puppet >>> version >>> I just get a "Reopening log files" in the syslog. On the other machines >>> this >>> is followed by "Starting Puppet client version 0.24.8" but on the new one >>> nothing happens. >> >> A bad part of this our fault. We need to send out FLAG days on certain >> packages (puppet being one of them) when an update goes into testing >> and when it goes into production. >> >> A second bad part is we do not keep many old versions of our packages >> around due to limits on resources on our part. > > I don't know about many versions but it would be good to have at least the > previous version around for a potential rollback.
We would need to keep several versions around because the rollback would have been 0.25.2 versus the 0.24.8 one you had on the system. >> Part of this is due to how puppet upstream works. Puppet only gives a >> partial guarantee for backwards compatibility between 'major' version >> upgrades (and only on the server), and the puppet recommended way of >> upgrades is always: >> >> Upgrade the server first, Upgrade the clients next. > > Should this 'major' update have been put into EPEL at all if there are known > backwards compatibility issues? That seems to be quite a risky policy for a > distribution which most people expect to be mostly free from any surprises > (as opposed to the faster moving desktop distros like Fedora). Here is where EPEL breaks down... certain software that people want very much does not stabilize and is moving forward all the time. If we were strictly going to do things, puppet and most of the things people ask for in EPEL would never be allowed in because their up-streams do not back-port and change their code so much between versions that back-porting is not possible. However, that would mean that we would only allow for software that hasn't changed since Red Hat Linux 7.1 which I think would be maybe bsd-games and fortune (maybe). People want newer stuff, and that comes with certain risks that really can't be dealt without serious dedicated resources. We should have announced this, but that would require people to 'know' they needed to read epel-announce or some rss feed before doing yum update. > Would a backup of /var/lib/puppet and /etc/puppet be sufficient when I > attempt to update the server? I manage 50+ machines with puppet and it would > be extremely painful to not be able to go back to a known working setup if > 0.25.4 shows problems. We have been using 0.25.x in Fedora infrastructure (100+ machines) for about a month before it got pushed to epel-stable. Backing up those directories should be enough. If you want to lower your risk lower, mirror what of the the repositories locally and use that to do updates to your boxes from. It is the method that Dag has pointed out for years and makes issues like this much easier to deal with no matter what the repository is. > Regards, > Dennis > > _______________________________________________ > epel-devel-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
