puppet 0.24.2

Jeroen van Meeuwen kanarip at kanarip.com
Thu Mar 20 10:59:07 UTC 2008


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 at 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




More information about the epel-devel-list mailing list