Re: Fixing Puppet in Fedora/EPEL
On Wed, Oct 24, 2012 at 07:21:40AM +0200, Vít Ondruch wrote: Dne 23.10.2012 17:21, Matthew Miller napsal(a): Once you introduce version into the name, you will never be able to get rid of it, although puppet 4 might be 100% compatible with That's not true. In the future, puppet can obsolete puppet3 -- for example, in EPEL 7. Yes, it can, but I doubt it will happen, because the arguments will be similar there are users which have scripts which has hardcoded puppet3 for some reason and it might break. This isn't about scripts as much as it is about yum update. Within a RHEL/EPEL-6 release, if the puppet package goes from 2.x to 3.x, that will break people's systems when they do a yum update. Between RHEL/EPEL-6 and RHEL/EPEL-7, people will have to do a fresh install of their hardware. At that time, they'll find out that puppet in EPEL7 is puppet-3.x and if they need to use puppet-2.x to work with their old puppetmaster they'll need to use a puppet2 package (provided that EPEL7 provides one of those). -Toshio pgphcvcR0jhqm.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On 10/23/2012 10:43 PM, Adam Williamson wrote: On Tue, 2012-10-23 at 15:47 +0200, Vít Ondruch wrote: Once you introduce version into the name, you will never be able to get rid of it, Of course you can. In fact we've done this more than once in Fedora. There was a gtk+3 package parallel installable with with 'gtk+' (which was a 2.x version) for a while; now 'gtk+' is 3.x. It's not a problem at all from a packaging perspective. Bad example there. In fact the gtk packages in Fedora are still: gtk+: 1.x gtk2: 2.x gtk3: 3.x Always have been, never changed. All parallel installable, all still in Fedora. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Wed, 2012-10-24 at 09:13 +0100, Paul Howarth wrote: On 10/23/2012 10:43 PM, Adam Williamson wrote: On Tue, 2012-10-23 at 15:47 +0200, Vít Ondruch wrote: Once you introduce version into the name, you will never be able to get rid of it, Of course you can. In fact we've done this more than once in Fedora. There was a gtk+3 package parallel installable with with 'gtk+' (which was a 2.x version) for a while; now 'gtk+' is 3.x. It's not a problem at all from a packaging perspective. Bad example there. In fact the gtk packages in Fedora are still: gtk+: 1.x gtk2: 2.x gtk3: 3.x Always have been, never changed. All parallel installable, all still in Fedora. Hum, you're right. Still, I know we've definitely done this before. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Fedora Infrastructure has begun using ansible for some system setup and other orchestration/automation tasks. Our (just beginning) public repos of it are here: http://infrastructure.fedoraproject.org/cgit/ansible.git/ Just out of my curiosity, is Fedora Infra going to replace Puppet with this, or you are planning to use these two technologies in parallel? Thanks -- Later, Lukas lzap Zapletal #katello #systemengine -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 07:35:28PM -0400, Matthew Miller wrote: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. Speaking for my previous job, it would really be unfortunate to have a non-compatible update of puppet in EPEL. Unless accompanied by very loud trumpets and fireworks beforehand, the day that update went out would be a very sad and busy day for a number of sysadmins. +1 I vote for having puppet3 and not touching the default version. This will be more challenging, but we all know a bit about puppet upgrades and transitions - it can be big pain. -- Later, Lukas lzap Zapletal #katello #systemengine -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
I'm sure that 2.6 won't last for the life of EL5, let alone EL6. At the same time, I didn't push to get 2.7 in EPEL because it isn't a completely compatible update. And 3.0 was coming so I figured we could wait to see what things looked like when it did. The alternative would have been more updates and more potential to break things and annoy the users who were perfectly happy with how 2.6 was working. (Those that needed the newest shiny or were supporting Fedora 17 could get newer bits from yum.puppetlabs.com.) Yes, but this this is not really necessary. From the EPEL FAQ: *** How long are EPEL packages updated? --- The plan is for EPEL packages to get updates as long as the corresponding RHEL release is supported. That is 10 years after the initial release according to the current errata support policy for 5 and 6 releases. How can we be sure that someone will maintain the packages until end of life of the distribution the packages were built for? - The only way to be sure is to do it yourself, which is coincidentally the reason EPEL was started in the first place. Software packages in EPEL are maintained on a voluntary basis. If you to want ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging. If you can, get your packaging role included as part of your job description; EPEL has written a generic description that you can use as the basis for adding to a job description. We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for. That is seven years after release (currently) -- a long time frame, and we know a lot can happen in seven years. Your participation is vital for the success of this project. *** Users have been warned (and asked for help). -- Later, Lukas lzap Zapletal #katello #systemengine -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Dne 23.10.2012 09:55, Lukas Zapletal napsal(a): On Fri, Oct 19, 2012 at 07:35:28PM -0400, Matthew Miller wrote: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. Speaking for my previous job, it would really be unfortunate to have a non-compatible update of puppet in EPEL. Unless accompanied by very loud trumpets and fireworks beforehand, the day that update went out would be a very sad and busy day for a number of sysadmins. +1 I vote for having puppet3 and not touching the default version. This will be more challenging, but we all know a bit about puppet upgrades and transitions - it can be big pain. Lets have puppet-3.x and puppet2 for whoever wants to use old version. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 01:57:13PM +0200, Vít Ondruch wrote: I vote for having puppet3 and not touching the default version. This will be more challenging, but we all know a bit about puppet upgrades and transitions - it can be big pain. Lets have puppet-3.x and puppet2 for whoever wants to use old version. But that doesn't help people running puppet 2.6 _now_, and just introduces complication into the packaging. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Dne 23.10.2012 15:10, Matthew Miller napsal(a): On Tue, Oct 23, 2012 at 01:57:13PM +0200, Vít Ondruch wrote: I vote for having puppet3 and not touching the default version. This will be more challenging, but we all know a bit about puppet upgrades and transitions - it can be big pain. Lets have puppet-3.x and puppet2 for whoever wants to use old version. But that doesn't help people running puppet 2.6 _now_, and just introduces complication into the packaging. Introducing new package is complication anyway, so what is the point? Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, 23 Oct 2012, Vít Ondruch wrote: Dne 23.10.2012 15:10, Matthew Miller napsal(a): On Tue, Oct 23, 2012 at 01:57:13PM +0200, Vít Ondruch wrote: Lets have puppet-3.x and puppet2 for whoever wants to use old version. But that doesn't help people running puppet 2.6 _now_, and just introduces complication into the packaging. Introducing new package is complication anyway, so what is the point? The problem is that upgrading from 2.6 to 2.7 (and therefore to 3) will almost certainly break things depending on how the update is done, for example resulting in clients that don't work against the server, so you don't want to break lots of puppet installations out there by automatically updating the puppet to version 3 which is what would happen if you changed the version in the puppet package. With a puppet3 package people can choose when they upgrade and do it in a controlled manner. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Dne 23.10.2012 15:37, Matthew Miller napsal(a): On Tue, Oct 23, 2012 at 03:22:27PM +0200, Vít Ondruch wrote: But that doesn't help people running puppet 2.6 _now_, and just introduces complication into the packaging. Introducing new package is complication anyway, so what is the point? See earlier comments. The point is that when the update goes live, people running the older version with non-compatible configs won't have their systems break. This is important. Yes, I understand that ... therefore you need two versions of puppet installed in parallel. There was proposal to prepare puppet3 package, while I think that the correct way is to move puppet to version 3 and prepare new puppet2 or compat-puppet package. Once you introduce version into the name, you will never be able to get rid of it, although puppet 4 might be 100% compatible with puppet 3 and I hope you don't like to have package puppet3-4.x in the future. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 8:47 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 23.10.2012 15:37, Matthew Miller napsal(a): On Tue, Oct 23, 2012 at 03:22:27PM +0200, Vít Ondruch wrote: But that doesn't help people running puppet 2.6 _now_, and just introduces complication into the packaging. Introducing new package is complication anyway, so what is the point? See earlier comments. The point is that when the update goes live, people running the older version with non-compatible configs won't have their systems break. This is important. Yes, I understand that ... therefore you need two versions of puppet installed in parallel. There was proposal to prepare puppet3 package, while I think that the correct way is to move puppet to version 3 and prepare new puppet2 or compat-puppet package. Once you introduce version into the name, you will never be able to get rid of it, although puppet 4 might be 100% compatible with puppet 3 and I hope you don't like to have package puppet3-4.x in the future. I'm still not sold on parallel installation being the solution for this situation. I get the idea behind it, but to me that just adds unnecessary complication to the whole thing. Not saying its not the route to go, just not at the top of my list. What I do think would be a good idea is if we could try addressing this issue from a higher level since Puppet is decidedly not the only package with this problem. but then... i've a vested interest in that concept because I started a thread about it on the epel-devel list last week (as Toshio mentioned earlier in this thread). https://www.redhat.com/archives/epel-devel-list/2012-October/msg00015.html -greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, 23 Oct 2012, Lukas Zapletal wrote: Fedora Infrastructure has begun using ansible for some system setup and other orchestration/automation tasks. Our (just beginning) public repos of it are here: http://infrastructure.fedoraproject.org/cgit/ansible.git/ Just out of my curiosity, is Fedora Infra going to replace Puppet with this, or you are planning to use these two technologies in parallel? As we move things into our private cloud instance we need a provisioning system that: 1. doesn't have a bunch of painful dependencies that go on every system (ruby) 2. doesn't require us to provision our systems before we provision our systems 3. doesn't require some other other daemon or cron job running on the systems to maintain them If it can take care of the needs we have I would certainly like to replace puppet. I do not speak for everyone work on the infrastructure team, but I am working on it as if our goal is replacement. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 03:47:43PM +0200, Vít Ondruch wrote: Yes, I understand that ... therefore you need two versions of puppet installed in parallel. There was proposal to prepare puppet3 package, while I think that the correct way is to move puppet to version 3 and prepare new puppet2 or compat-puppet package. That's probably correct for a new major release. It's not okay during the lifecycle of a stable product, if we can avoid it. (Sometimes we can't. We're not at can't yet for this.) Once you introduce version into the name, you will never be able to get rid of it, although puppet 4 might be 100% compatible with That's not true. In the future, puppet can obsolete puppet3 -- for example, in EPEL 7. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
I am still not in favor of a puppet3 package. This is largely due to overall compatibility. Puppet is a distributed system. Having the package be called puppet in some repositories and puppet3 in others (along with bin files/utils) will only the make the overall user-experience of Puppet worse IMHO. Also if the existing Puppet (2.6.x) stays out there, how would a user know that 2.6 is no longer maintained? Does having a second package without an upgrade path leaves the end-user out-to-dry in the longrun? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 11:30:49AM -0700, Michael Stahnke wrote: I am still not in favor of a puppet3 package. This is largely due to overall compatibility. Puppet is a distributed system. Having the package be called puppet in some repositories and puppet3 in others (along with bin files/utils) will only the make the overall user-experience of Puppet worse IMHO. Also if the existing Puppet (2.6.x) stays out there, how would a user know that 2.6 is no longer maintained? Does having a second package without an upgrade path leaves the end-user out-to-dry in the longrun? We can make the new package available, and do something to publicize that there is going to be a change. When 2.6.x is no longer maintained for security updates, the new package gets the old name and obsoletes the temporary name. If there's some way to put deprecation notices into the default output for puppet, it might be worth considering that. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 12:46 PM, Matthew Miller mat...@fedoraproject.org wrote: We can make the new package available, and do something to publicize that there is going to be a change. When 2.6.x is no longer maintained for security updates, the new package gets the old name and obsoletes the temporary name. There will have to be a public announcement either way, so I would prefer to have the public announcement be Puppet 3 is coming to EPEL; please test it in updates-testing, and if you don't want it, please block it on your local systems. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 1:46 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Oct 23, 2012 at 11:30:49AM -0700, Michael Stahnke wrote: I am still not in favor of a puppet3 package. This is largely due to overall compatibility. Puppet is a distributed system. Having the package be called puppet in some repositories and puppet3 in others (along with bin files/utils) will only the make the overall user-experience of Puppet worse IMHO. Also if the existing Puppet (2.6.x) stays out there, how would a user know that 2.6 is no longer maintained? Does having a second package without an upgrade path leaves the end-user out-to-dry in the longrun? We can make the new package available, and do something to publicize that there is going to be a change. When 2.6.x is no longer maintained for security updates, the new package gets the old name and obsoletes the temporary name. If there's some way to put deprecation notices into the default output for puppet, it might be worth considering that. An easy way would be to roll and update to the 2.6 release that logs a deprecation error on start via the init script. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
From: Greg Swift xa...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Date: 10/23/2012 15:51 Subject: Re: Fixing Puppet in Fedora/EPEL Sent by: devel-boun...@lists.fedoraproject.org On Tue, Oct 23, 2012 at 1:46 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Oct 23, 2012 at 11:30:49AM -0700, Michael Stahnke wrote: I am still not in favor of a puppet3 package. This is largely due to overall compatibility. Puppet is a distributed system. Having the package be called puppet in some repositories and puppet3 in others (along with bin files/utils) will only the make the overall user-experience of Puppet worse IMHO. Also if the existing Puppet (2.6.x) stays out there, how would a user know that 2.6 is no longer maintained? Does having a second package without an upgrade path leaves the end-user out-to-dry in the longrun? We can make the new package available, and do something to publicize that there is going to be a change. When 2.6.x is no longer maintained for security updates, the new package gets the old name and obsoletes the temporary name. If there's some way to put deprecation notices into the default output for puppet, it might be worth considering that. An easy way would be to roll and update to the 2.6 release that logs a deprecation error on start via the init script. And ideally the message would also land in the tagmail deliveries once upon first catalog compilation after the puppet master is restarted -- much like the 2.7 deprecation notice for dynamically scoped variables was handled. That was a very nice compromise between (1) you should see this and (2) not being annoying about it. I would personally like to see the puppet folks adopt something like this as an ongoing policy for all deprecations/obsoletions with as much as advance notice as reasonably possible. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, 2012-10-23 at 15:47 +0200, Vít Ondruch wrote: Once you introduce version into the name, you will never be able to get rid of it, Of course you can. In fact we've done this more than once in Fedora. There was a gtk+3 package parallel installable with with 'gtk+' (which was a 2.x version) for a while; now 'gtk+' is 3.x. It's not a problem at all from a packaging perspective. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Sat, Oct 20, 2012 at 1:04 AM, Michael Stahnke stah...@puppetlabs.com wrote: Puppet in the Fedora/EPEL ecosystem is a bit wonky currently. I'd really like to fix it. Problems: * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x. 2.7.x is not 100% compatible with 1.9.3. The number of issues in this space continues to grow. * Puppet 3.0.x is out and is the fully supported branch from Puppet Labs and supports Ruby 1.9.3+ fully. My proposal would be the following: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. What about ruby on RHEL6? Will puppet 3.0 work with RHEL6's ruby 1.8.7, or do you expect RHEL6 users to replace the distro native ruby stack ? -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 2:50 PM, Jan-Frode Myklebust janfr...@tanso.net wrote: On Sat, Oct 20, 2012 at 1:04 AM, Michael Stahnke stah...@puppetlabs.com wrote: Puppet in the Fedora/EPEL ecosystem is a bit wonky currently. I'd really like to fix it. Problems: * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x. 2.7.x is not 100% compatible with 1.9.3. The number of issues in this space continues to grow. * Puppet 3.0.x is out and is the fully supported branch from Puppet Labs and supports Ruby 1.9.3+ fully. My proposal would be the following: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. What about ruby on RHEL6? Will puppet 3.0 work with RHEL6's ruby 1.8.7, or do you expect RHEL6 users to replace the distro native ruby stack ? 1.8.7 is fully supported in Puppet 3.0 -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Dne 23.10.2012 17:21, Matthew Miller napsal(a): Once you introduce version into the name, you will never be able to get rid of it, although puppet 4 might be 100% compatible with That's not true. In the future, puppet can obsolete puppet3 -- for example, in EPEL 7. Yes, it can, but I doubt it will happen, because the arguments will be similar there are users which have scripts which has hardcoded puppet3 for some reason and it might break. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
From: Seth Vidal skvi...@fedoraproject.org On Fri, 19 Oct 2012, Michael Stahnke wrote: On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal On Fri, 19 Oct 2012, Michael Stahnke wrote: I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. I'm more worried about people with hybrid environments where RHEL is at the core for Puppet. (and somewhat how RHEL 7 could shake out) Do you consider it ok to not be able to have Fedora agents check into a RHEL master? There is a reason I want to move to a clientless configmgmt infrastructure. I do not want to be hogtied like this again. I cannot speak for Fedora infrastructure, but I committed to puppet completely at work at home before realizing the horrible situation that puppet's client/server has forced on its users. While it looks like they're heading in the right direction, it does us early adopters no good to struggle through this incompatibility entanglement. Too much of what once was shown as the way, if not the best practice, is no longer even supported (e.g., dynamically scoped variables). My first use of puppet required operation from cached resources on stateless Fedora nodes in the event that the network was offline or the master otherwise unreachable. I could not make the normal client/server approach work and thus adopted a rsync + cron + puppet agent apply approach as a work around. That to date has still been my best experience with puppet -- it just works because it abandons the requirements imposed by their client/server approach. As for what should be done with Fedora and RHEL I cannot say. It seems all available options stink. On one hand I'd hate to see F17 change, I'm still struggling to adjust my code to be compatible with that. I've had a difficult time keeping my puppet resources in shape for each Fedora release -- six months goes by all to fast when you have many other responsibilities -- puppet was supposed to reduce my workload, right? Right??? If 3.0 lands in F17, that's going to hurt my plans. At the same time, puppet in F17 as is is plagued with problems as already mentioned. Argh! Hogtied is a very apt description. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
From: Matthew Miller mat...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: epel-devel-l...@redhat.com Date: 10/19/2012 19:35 Subject: Re: Fixing Puppet in Fedora/EPEL Sent by: devel-boun...@lists.fedoraproject.org On Fri, Oct 19, 2012 at 04:04:24PM -0700, Michael Stahnke wrote: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. Speaking for my previous job, it would really be unfortunate to have a non-compatible update of puppet in EPEL. Unless accompanied by very loud trumpets and fireworks beforehand, the day that update went out would be a very sad and busy day for a number of sysadmins. I'm not opposed to putting puppet 3 in, but it'd really be helpful if it went in as puppet3 or something, and left the stable version as is, happily getting security-only updates. Yes, please! Something like that would be great. It was done for bacula (and may still be). I did finally get off bacula2, but it took a long time because I had many clients that couldn't run anything else and updating those clients (OS-wise) had many dependencies of their own. It's a simple unavoidable fact that some systems just cannot stay as current as they ideally should and the dependencies may run very deep and well beyond the realm of software packages and OSes alone. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Sat, Oct 20, 2012 at 1:31 AM, Seth Vidal skvi...@fedoraproject.org wrote: There is a reason I want to move to a clientless configmgmt infrastructure. Could you explain what you mean by clientless, please? It seems to me that there always needs to be something running at the client handling the data from the server, and therefore there needs to be either a protocol or a data format the client and the server have in common. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, 22 Oct 2012, Miloslav Trmač wrote: On Sat, Oct 20, 2012 at 1:31 AM, Seth Vidal skvi...@fedoraproject.org wrote: There is a reason I want to move to a clientless configmgmt infrastructure. Could you explain what you mean by clientless, please? It seems to me that there always needs to be something running at the client handling the data from the server, and therefore there needs to be either a protocol or a data format the client and the server have in common. http://ansible.cc It connects via ssh, pushes the code it needs to run over and executes it. You're right that it does require something running on the client: sshd From a software standpoint it assumes you have python installed on the clients, but that's only by default, you could write modules instead in plain shell or in C and it would work just fine. It counts on json for output. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
From: Seth Vidal skvi...@fedoraproject.org On Mon, 22 Oct 2012, Miloslav Trmač wrote: On Sat, Oct 20, 2012 at 1:31 AM, Seth Vidal skvi...@fedoraproject.org wrote: There is a reason I want to move to a clientless configmgmt infrastructure. Could you explain what you mean by clientless, please? It seems to me that there always needs to be something running at the client handling the data from the server, and therefore there needs to be either a protocol or a data format the client and the server have in common. http://ansible.cc It connects via ssh, pushes the code it needs to run over and executes it. You're right that it does require something running on the client: sshd From a software standpoint it assumes you have python installed on the clients, but that's only by default, you could write modules instead in plain shell or in C and it would work just fine. It counts on json for output. ansibile is exactly what I've been looking at as a puppet replacement. If anyone has experience with both, I'd greatly appreciate hearing of their experiences. I don't relish the idea of making the conversion, but I really do get the impression life would be simpler with ansible once there. Or am I just falling for that greener grass on the other side of the fence? -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, 22 Oct 2012, john.flor...@dart.biz wrote: ansibile is exactly what I've been looking at as a puppet replacement. If anyone has experience with both, I'd greatly appreciate hearing of their experiences. I don't relish the idea of making the conversion, but I really do get the impression life would be simpler with ansible once there. Or am I just falling for that greener grass on the other side of the fence? Fedora Infrastructure has begun using ansible for some system setup and other orchestration/automation tasks. Our (just beginning) public repos of it are here: http://infrastructure.fedoraproject.org/cgit/ansible.git/ -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, Oct 22, 2012 at 5:31 AM, john.flor...@dart.biz wrote: From: Seth Vidal skvi...@fedoraproject.org On Fri, 19 Oct 2012, Michael Stahnke wrote: On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal On Fri, 19 Oct 2012, Michael Stahnke wrote: I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. I'm more worried about people with hybrid environments where RHEL is at the core for Puppet. (and somewhat how RHEL 7 could shake out) Do you consider it ok to not be able to have Fedora agents check into a RHEL master? There is a reason I want to move to a clientless configmgmt infrastructure. I do not want to be hogtied like this again. I cannot speak for Fedora infrastructure, but I committed to puppet completely at work at home before realizing the horrible situation that puppet's client/server has forced on its users. While it looks like they're heading in the right direction, it does us early adopters no good to struggle through this incompatibility entanglement. Too much of what once was shown as the way, if not the best practice, is no longer even supported (e.g., dynamically scoped variables). My first use of puppet required operation from cached resources on stateless Fedora nodes in the event that the network was offline or the master otherwise unreachable. I could not make the normal client/server approach work and thus adopted a rsync + cron + puppet agent apply approach as a work around. That to date has still been my best experience with puppet -- it just works because it abandons the requirements imposed by their client/server approach. As for what should be done with Fedora and RHEL I cannot say. It seems all available options stink. On one hand I'd hate to see F17 change, I'm still struggling to adjust my code to be compatible with that. I've had a difficult time keeping my puppet resources in shape for each Fedora release -- six months goes by all to fast when you have many other responsibilities -- puppet was supposed to reduce my workload, right? Right??? If 3.0 lands in F17, that's going to hurt my plans. At the same time, puppet in F17 as is is plagued with problems as already mentioned. Argh! Hogtied is a very apt description. I'm sorry if your Puppet experience isn't completely awesome. Posting on the Puppet users list might be more appropriate. In this case I am looking for packaging options/opinions on Puppet with regards to Fedora and EPEL. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
From: Michael Stahnke stah...@puppetlabs.com On Mon, Oct 22, 2012 at 5:31 AM, john.flor...@dart.biz wrote: From: Seth Vidal skvi...@fedoraproject.org On Fri, 19 Oct 2012, Michael Stahnke wrote: On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal On Fri, 19 Oct 2012, Michael Stahnke wrote: I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. I'm more worried about people with hybrid environments where RHEL is at the core for Puppet. (and somewhat how RHEL 7 could shake out) Do you consider it ok to not be able to have Fedora agents check into a RHEL master? There is a reason I want to move to a clientless configmgmt infrastructure. I do not want to be hogtied like this again. I cannot speak for Fedora infrastructure, but I committed to puppet completely at work at home before realizing the horrible situation that puppet's client/server has forced on its users. While it looks like they're heading in the right direction, it does us early adopters no good to struggle through this incompatibility entanglement. Too much of what once was shown as the way, if not the best practice, is no longer even supported (e.g., dynamically scoped variables). My first use of puppet required operation from cached resources onstateless Fedora nodes in the event that the network was offline or the master otherwise unreachable. I could not make the normal client/server approach work and thus adopted a rsync + cron + puppet agent apply approachas a work around. That to date has still been my best experience with puppet -- it just works because it abandons the requirements imposed by their client/server approach. As for what should be done with Fedora and RHEL I cannot say. It seems all available options stink. On one hand I'd hate to see F17 change, I'm still struggling to adjust my code to be compatible with that. I've had a difficult time keeping my puppet resources in shape for each Fedora release -- six months goes by all to fast when you have many other responsibilities -- puppet was supposed to reduce my workload, right? Right??? If3.0 lands in F17, that's going to hurt my plans. At the same time, puppet in F17 as is is plagued with problems as already mentioned. Argh! Hogtied is a very apt description. I'm sorry if your Puppet experience isn't completely awesome. Posting on the Puppet users list might be more appropriate. Been there, done that since v0.24. If I'd jumped in with 3.0, my opinions might be different. I believe something like puppet is sorely needed and it solves big problems, but it's been a very bumpy ride when what was once best practice is now deprecated. In this case I am looking for packaging options/opinions on Puppet with regards to Fedora and EPEL. See my next to last paragraph beginning, As for what should be done with Fedora and RHEL Consider the rest as context. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller mat...@fedoraproject.org wrote: I'm not opposed to putting puppet 3 in, but it'd really be helpful if it went in as puppet3 or something, and left the stable version as is, happily getting security-only updates. My biggest concern is that 2.6 will not get security updates for the lifetime of EPEL 5 and 6. To me it seems better to bite the bullet now, get version 3 into updates-testing, set the karma requirement very high just as the maintainers did for the 0.25 - 2.6 transition. This is the main problem I see with parallel-installable packages, particularly in EPEL - it seems to give users an assumption that the old packages are fine. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, Oct 22, 2012 at 12:25:22PM -0600, Ken Dreyer wrote: I'm not opposed to putting puppet 3 in, but it'd really be helpful if it went in as puppet3 or something, and left the stable version as is, happily getting security-only updates. My biggest concern is that 2.6 will not get security updates for the lifetime of EPEL 5 and 6. To me it seems better to bite the bullet As I understand it, Puppet Labs is still providing security updates for the 2.6 series. This is the main problem I see with parallel-installable packages, particularly in EPEL - it seems to give users an assumption that the old packages are fine. We should cross that bridge when the old packages aren't fine anymore. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Ken Dreyer wrote: On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller mat...@fedoraproject.org wrote: I'm not opposed to putting puppet 3 in, but it'd really be helpful if it went in as puppet3 or something, and left the stable version as is, happily getting security-only updates. My biggest concern is that 2.6 will not get security updates for the lifetime of EPEL 5 and 6. To me it seems better to bite the bullet now, get version 3 into updates-testing, set the karma requirement very high just as the maintainers did for the 0.25 - 2.6 transition. I'm sure that 2.6 won't last for the life of EL5, let alone EL6. At the same time, I didn't push to get 2.7 in EPEL because it isn't a completely compatible update. And 3.0 was coming so I figured we could wait to see what things looked like when it did. The alternative would have been more updates and more potential to break things and annoy the users who were perfectly happy with how 2.6 was working. (Those that needed the newest shiny or were supporting Fedora 17 could get newer bits from yum.puppetlabs.com.) This is the main problem I see with parallel-installable packages, particularly in EPEL - it seems to give users an assumption that the old packages are fine. Yeah, that's always bugged me too. If you're not paying close attention, you can easily assume that since yum update returns nothing that you are good to go. In that case, I'd much prefer that an update comes along and gets your attention, even if it breaks things. Obviously, neither option is all that great. As a user, I think compatibility is the biggest downside to puppet at this point. I love the tool, but having to always run the master on the latest version bugs me. At the least, I think a version N client should work fine with an N-1 master. Back in the pre-1.0 days it was acceptable to not have this, but as the versions have been increased to show product maturity, I think it's hard to justify not maintaining more compatibility. I'm happy to see options here and get a feel for what the least painful way forward is for everyone. I'm not terribly fond of a puppet3 package myself. It would be confusing to have it parallel installable and use different paths than the upstream defaults, as documenation would either be wrong or require a lot of conditional statements regarding where and how you installed puppet. That and it's more work to maintain, regardless of who's maintaining it. Thanks to Michael for bringing this topic up for discussion (and for being an all around good guy as well). -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Abandon the search for Truth; settle for a good fantasy. pgpTTcYp3nbsP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Mon, Oct 22, 2012 at 7:51 PM, Todd Zullinger t...@pobox.com wrote: Ken Dreyer wrote: On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller mat...@fedoraproject.org wrote: I'm not opposed to putting puppet 3 in, but it'd really be helpful if it went in as puppet3 or something, and left the stable version as is, happily getting security-only updates. My biggest concern is that 2.6 will not get security updates for the lifetime of EPEL 5 and 6. To me it seems better to bite the bullet now, get version 3 into updates-testing, set the karma requirement very high just as the maintainers did for the 0.25 - 2.6 transition. I'm sure that 2.6 won't last for the life of EL5, let alone EL6. At the same time, I didn't push to get 2.7 in EPEL because it isn't a completely compatible update. And 3.0 was coming so I figured we could wait to see what things looked like when it did. The alternative would have been more updates and more potential to break things and annoy the users who were perfectly happy with how 2.6 was working. (Those that needed the newest shiny or were supporting Fedora 17 could get newer bits from yum.puppetlabs.com.) 2.6.x will be maintained (security) roughly until end of Q1 next year. That's the only real commitment we can make. It's not that we'd completely leave everybody in the dark after that, but some fixes/issues just don't port well to older versions. So this is well short of EPEL5/6 lifetimes. This is the main problem I see with parallel-installable packages, particularly in EPEL - it seems to give users an assumption that the old packages are fine. I too have always thought this. Yeah, that's always bugged me too. If you're not paying close attention, you can easily assume that since yum update returns nothing that you are good to go. In that case, I'd much prefer that an update comes along and gets your attention, even if it breaks things. Obviously, neither option is all that great. As a user, I think compatibility is the biggest downside to puppet at this point. I love the tool, but having to always run the master on the latest version bugs me. At the least, I think a version N client should work fine with an N-1 master. Back in the pre-1.0 days it was acceptable to not have this, but as the versions have been increased to show product maturity, I think it's hard to justify not maintaining more compatibility. This is an ongoing discussion internally on compatibility. Thoughts and opinions and real-world use cases from system admins are MORE than welcome about this topic on our puppet-users list. I'm happy to see options here and get a feel for what the least painful way forward is for everyone. I'm not terribly fond of a puppet3 package myself. It would be confusing to have it parallel installable and use different paths than the upstream defaults, as documenation would either be wrong or require a lot of conditional statements regarding where and how you installed puppet. That and it's more work to maintain, regardless of who's maintaining it. Thanks to Michael for bringing this topic up for discussion (and for being an all around good guy as well). cheers. -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Abandon the search for Truth; settle for a good fantasy. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
Hi, On Fri, 19 Oct 2012 16:29:57 -0700 Michael Stahnke stah...@puppetlabs.com wrote: On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidalskvi...@fedoraproject.org wrote: I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. I'm more worried about people with hybrid environments where RHEL is at the core for Puppet. (and somewhat how RHEL 7 could shake out) Do you consider it ok to not be able to have Fedora agents check into a RHEL master? FWIW, we have exactly this (Fedora clients, CentOS master). And yes, we need to use our local mirror of yum.puppetlabs.com right now. This is nothing more than anecdata, as we are fine with the setup now. Of course, having puppet3 in EPEL would make life a tiny bit easier. Regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Michael Stahnke wrote: Puppet in the Fedora/EPEL ecosystem is a bit wonky currently. I'd really like to fix it. Problems: * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x. 2.7.x is not 100% compatible with 1.9.3. The number of issues in this space continues to grow. * EPEL 5/6 still have Puppet 2.6.x in stable. This version of Puppet isn't maintained any more, other than security fixes. Isn't 'not maintained anymore other than security fixes' Exactly what epel (and rhel for that matter) all about? also - if I have a puppet master on rhel5 and my clients on rhel6 - how well does that work? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 4:05 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Fri, 19 Oct 2012, Michael Stahnke wrote: Puppet in the Fedora/EPEL ecosystem is a bit wonky currently. I'd really like to fix it. Problems: * Fedora 17 (and higher) ships with Ruby 1.9.x and Puppet 2.7.x. 2.7.x is not 100% compatible with 1.9.3. The number of issues in this space continues to grow. * EPEL 5/6 still have Puppet 2.6.x in stable. This version of Puppet isn't maintained any more, other than security fixes. Isn't 'not maintained anymore other than security fixes' Exactly what epel (and rhel for that matter) all about? Yes, and no. You'd never be able to have Fedora clients (or many other distributions/OSes) connecting to that master. also - if I have a puppet master on rhel5 and my clients on rhel6 - how well does that work? Right, in this world you'd want to put a master on EL6 or newer. I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Michael Stahnke wrote: I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. Perhaps they aren't likely to run epel, except it feels like they will run epel. b/c it is pushed so hard by all the el6's. I agree it is a suboptimal solution. Hey, since you work for puppetlabs - I have a new idea - make them maintain backward compat with 2.6 :) That solves the problem for everyone, right? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Fri, 19 Oct 2012, Michael Stahnke wrote: I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. I'm more worried about people with hybrid environments where RHEL is at the core for Puppet. (and somewhat how RHEL 7 could shake out) Do you consider it ok to not be able to have Fedora agents check into a RHEL master? Perhaps they aren't likely to run epel, except it feels like they will run epel. b/c it is pushed so hard by all the el6's. I agree it is a suboptimal solution. Hey, since you work for puppetlabs - I have a new idea - make them maintain backward compat with 2.6 :) Well, yes and no. We are trying very hard with the 3 series to not break compatibility. 2.6 and even 2.7 had some ambiguous behavior that is now better defined which does help that. That solves the problem for everyone, right? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Michael Stahnke wrote: On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Fri, 19 Oct 2012, Michael Stahnke wrote: I (we) completely realize this isn't totally awesome either. This is a problem when you have a distributed application that is trying to support the widest variety of host populations we can. This request was brought to us by community members, Red Hat employees, and business partners as well. I am happy to discuss other soutions/ideas too though. I am not 100% convinced my proposal is the best. I'm less worried about the people requesting the newness b/c they clearly want change. I'm worried about the people who run rhel b/c they fear change. I'm more worried about people with hybrid environments where RHEL is at the core for Puppet. (and somewhat how RHEL 7 could shake out) Do you consider it ok to not be able to have Fedora agents check into a RHEL master? There is a reason I want to move to a clientless configmgmt infrastructure. I do not want to be hogtied like this again. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 04:04:24PM -0700, Michael Stahnke wrote: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. Speaking for my previous job, it would really be unfortunate to have a non-compatible update of puppet in EPEL. Unless accompanied by very loud trumpets and fireworks beforehand, the day that update went out would be a very sad and busy day for a number of sysadmins. I'm not opposed to putting puppet 3 in, but it'd really be helpful if it went in as puppet3 or something, and left the stable version as is, happily getting security-only updates. (I agree that we need to find a better solution to this long term. But that's what we've got.) The same _probably_ goes for F17. And, technically, it's getting _really late_ for big changes for F18 -- the change deadline is the 26th, so we should hurry with that if possible. Puppet Labs release engineering is more than willing to do a majority of this work to make this happen. That is awesome. I very much support getting puppet into better shape in Fedora, and your participation is great. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 07:31:57PM -0400, Seth Vidal wrote: There is a reason I want to move to a clientless configmgmt infrastructure. I do not want to be hogtied like this again. Yeah, but we're not going to make _you_ use Puppet. :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Matthew Miller wrote: On Fri, Oct 19, 2012 at 07:31:57PM -0400, Seth Vidal wrote: There is a reason I want to move to a clientless configmgmt infrastructure. I do not want to be hogtied like this again. Yeah, but we're not going to make _you_ use Puppet. :) Damned if some folks don't seem to try. ;) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 5:04 PM, Michael Stahnke stah...@puppetlabs.com wrote: My proposal would be the following: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. * Move EPEL 5 to the latest 2.7.x branch. This is the last branch of Puppet that supports Ruby 1.8.5, and works with 3.0 masters. The last big Puppet move in EPEL (0.25 to 2.6) went well, so I welcome this change. - Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 07:35:28PM -0400, Matthew Miller wrote: On Fri, Oct 19, 2012 at 04:04:24PM -0700, Michael Stahnke wrote: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. Speaking for my previous job, it would really be unfortunate to have a non-compatible update of puppet in EPEL. Unless accompanied by very loud trumpets and fireworks beforehand, the day that update went out would be a very sad and busy day for a number of sysadmins. I'm not opposed to putting puppet 3 in, but it'd really be helpful if it went in as puppet3 or something, and left the stable version as is, happily getting security-only updates. Having a parallel installable package makes sense to me. If it can't be parallel installed -- perhaps the question of whether to allow conflicts in epel that was recently raised would be a good thing to look at here as well? https://www.redhat.com/archives/epel-devel-list/2012-October/msg00015.html -Toshio pgpNc4MX2O6Nf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, 19 Oct 2012, Ken Dreyer wrote: On Fri, Oct 19, 2012 at 5:04 PM, Michael Stahnke stah...@puppetlabs.com wrote: My proposal would be the following: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. * Move EPEL 5 to the latest 2.7.x branch. This is the last branch of Puppet that supports Ruby 1.8.5, and works with 3.0 masters. The last big Puppet move in EPEL (0.25 to 2.6) went well, so I welcome this change. It did? Istr a number of things on our systems going completely sideways. Maybe that was a different transition. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Fri, Oct 19, 2012 at 5:02 PM, Seth Vidal skvi...@fedoraproject.org wrote: On Fri, 19 Oct 2012, Ken Dreyer wrote: On Fri, Oct 19, 2012 at 5:04 PM, Michael Stahnke stah...@puppetlabs.com wrote: My proposal would be the following: * Move EPEL 6, Fedora = 17 to use Puppet 3.0. * Move EPEL 5 to the latest 2.7.x branch. This is the last branch of Puppet that supports Ruby 1.8.5, and works with 3.0 masters. The last big Puppet move in EPEL (0.25 to 2.6) went well, so I welcome this change. It did? Istr a number of things on our systems going completely sideways. Maybe that was a different transition. As a note, I was able to upgrade from 2.6 to 2.7 with minor changes. From 2.7 to 3.0 with _NONE_ on my infrastructure. -sv ___ epel-devel-list mailing list epel-devel-l...@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
