This mail (thread) about puppet-0.24.2 from the fedora-infrastructure-list I was pointed to when yesterday I found out a couple of managed machines did not behave as expected.
Mike McGrath wrote:
On Thu, 6 Mar 2008, Stephen John Smoogen wrote:
On Thu, Mar 6, 2008 at 2:14 PM, Mike McGrath mmcgrath@redhat.com wrote:
Beware! Don't do it!
puppet 0.24.2 has been released and is in epel testing, which means if you yum update a machine... it'll get picked up. And it doesn't work with our setup. The 0.24.2 puppet nodes are not compatable with 0.24.1 puppet masters.
I (or someone) will need to test some things before doing this upgrade.
Ouch. That's uhm not a minor update :). Well it could be worse (... plunges through cfengine minor update changes..)
In fairness to the puppet guys I talked to them about it and they said it should be considered a bug, just one that slipped into the release.
It'd be the second time puppet gets upgrades in EPEL with unstable API/behaviour, this time it even manages to destroy a couple of boxes. One of many, many files managed by puppet on an EL4 box with puppet-master running on a EL5 box:
[root@app20 ~]# cat /etc/nagios/nrpe.cfg 420 file 0 0 {md5}c6519debb77ad5428c6d3d678da81f99[root@app20 ~]#
Same thing happened at home where Fedora 8 runs a puppet-master for a couple of Fedora 7 and EL5 boxes.
The most amazing thing is... EL4 boxes get the update (becoming incompatible with the EL5 box managing them) before even my Fedora 8 box (managing a couple of EL5 boxes) knows about it in updates-testing.
I'm sure you all appreciate people are running *enterprise linux* for a reason, and do not want to bother with package foo like this like if it were Fedora.
Jeroen van Meeuwen wrote:
I'm sure you all appreciate people are running *enterprise linux* for a reason, and do not want to bother with package foo like this like if it were Fedora.
Breaking user configuration shouldn't be done in Fedora updates either.
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
I'm sure you all appreciate people are running *enterprise linux* for a reason, and do not want to bother with package foo like this like if it were Fedora.
Breaking user configuration shouldn't be done in Fedora updates either.
This isn't about Fedora. This doesn't concern Fedora.
I just wish I could count on the Enterprise Linux branch - with or without EPEL and/or subscriptions and/or a toll-free number - to be more stable, so that there's actually a good (and valid!) reason to use it.
On Wed, Mar 19, 2008 at 5:11 PM, Jeroen van Meeuwen kanarip@kanarip.com wrote:
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
I'm sure you all appreciate people are running *enterprise linux* for a reason, and do not want to bother with package foo like this like if it were Fedora.
Breaking user configuration shouldn't be done in Fedora updates either.
This isn't about Fedora. This doesn't concern Fedora.
I just wish I could count on the Enterprise Linux branch - with or without EPEL and/or subscriptions and/or a toll-free number - to be more stable, so that there's actually a good (and valid!) reason to use it.
-- Kind regards,
Jeroen van Meeuwen -kanarip
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Do you test every update before you automatically apply it to production systems? I know my enterprise sure does. While normally updates are harmless, I have seen RHEL updates (the ones we pay for) that have erased /var/named, edited /etc/syslog.conf and probably a lot more stuff that I can't recall off the top of my head. If you suicide update, I don't think it's very fair to get mad at the volunteers trying to provide you software. Yes, it was a bug in puppet. I understand this. They shipped it, we packaged it.
Unfortunately, right now due to people/resource constraints in EPEL, we push RHEL4/5 and Fedora updates on a separate schedule. Fedora uses a completely different build/update system than EPEL currently can. There is a lot of effort underway to to move our build system to the same as Fedora's, but still we will have a few timing issues between Fedora and EPEL4 and EPEL5. It is less than ideal but we are working to make it better.
stahnma
Michael Stahnke wrote:
Do you test every update before you automatically apply it to production systems?
Fedora? Yes. EL? No. I wouldn't bluntly yum -d0 -e0 -y update, but testing the updates before applying them just doesn't scale very well. Sure we freeze versions etc, and we might need to do so for puppet as well. I'll get it to work, eventually, one way or the other.
I know my enterprise sure does. While normally
updates are harmless, I have seen RHEL updates (the ones we pay for) that have erased /var/named, edited /etc/syslog.conf and probably a lot more stuff that I can't recall off the top of my head.
Admittedly, I've seen this kind of thing too. You do agree that's a bad thing, right?
If you
suicide update, I don't think it's very fair to get mad at the volunteers trying to provide you software. Yes, it was a bug in puppet. I understand this. They shipped it, we packaged it.
Don't misunderstand me, I'm not mad. Honestly though, I /did/ get mad (confused over my own ignorance if you will), and I realized I can't direct that at volunteers (dlutter@redhat.com is the maintainer in this case?). However, I /do/ want to find out if and how we can avoid this kind of thing happening again in the future. Most packages live in Fedora for a while, before they get pushed anywhere else. That process proved itself to work quite well.
Unfortunately, right now due to people/resource constraints in EPEL, we push RHEL4/5 and Fedora updates on a separate schedule. Fedora uses a completely different build/update system than EPEL currently can. There is a lot of effort underway to to move our build system to the same as Fedora's, but still we will have a few timing issues between Fedora and EPEL4 and EPEL5. It is less than ideal but we are working to make it better.
I know, I'm not a complete stranger with EPEL (since Boston 2007's FUDCon, at least).
Kind regards,
Jeroen van Meeuwen -kanarip
On Thu, Mar 20, 2008 at 4:59 AM, Jeroen van Meeuwen kanarip@kanarip.com wrote:
Michael Stahnke wrote:
Do you test every update before you automatically apply it to production systems?
Fedora? Yes. EL? No. I wouldn't bluntly yum -d0 -e0 -y update, but testing the updates before applying them just doesn't scale very well. Sure we freeze versions etc, and we might need to do so for puppet as well. I'll get it to work, eventually, one way or the other.
I know my enterprise sure does. While normallyupdates are harmless, I have seen RHEL updates (the ones we pay for) that have erased /var/named, edited /etc/syslog.conf and probably a lot more stuff that I can't recall off the top of my head.
Admittedly, I've seen this kind of thing too. You do agree that's a bad thing, right?
I agree its bad, but I know that its going to happen no matter how diligent Red Hat is in testing things... and so I need to be prepared to deal with it.
If you
suicide update, I don't think it's very fair to get mad at the volunteers trying to provide you software. Yes, it was a bug in puppet. I understand this. They shipped it, we packaged it.
Don't misunderstand me, I'm not mad. Honestly though, I /did/ get mad (confused over my own ignorance if you will), and I realized I can't direct that at volunteers (dlutter@redhat.com is the maintainer in this case?). However, I /do/ want to find out if and how we can avoid this kind of thing happening again in the future. Most packages live in Fedora for a while, before they get pushed anywhere else. That process proved itself to work quite well.
Someone should have caught this in epel-testing. However, I am not sure we have enough people using it for it to be 'useful' in all cases. It would be great if we had a formal test-buddy for every package that said "Tested package, ran through results, and works for me." but we currently do not. If you can help out on this with puppet it would be appreciated.
epel-devel@lists.fedoraproject.org
-
Jeroen van Meeuwen -
Michael Stahnke -
Rahul Sundaram -
Stephen John Smoogen