Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On 10/07/2012 11:28 PM, Sandra Schlichting wrote: I know for that practice, but the problem is that it makes upgrade from samba to samba3x packages a problem. So I would rather avoid that with the puppet. And if you know how to add puppetlabs repo to yum, then you'll know how to choose what version repo to use. Just take a look at postgresql repositories. I would very much like how to do that, as it seams to me that yum versionlock locks the current installed package from being upgraded, which is not really what we want =) We want that puppet-2.7.* and puppet-server-2.7.* can be upgraded. Currently the only way I know is to make your own repositories... We we're chatting about what policy should puppetlabs adopt, and not how to solve the current problem. Currently the only way is to go with ensure = present + versionlock, and to manually change the lock when new version is out :( -- Jakov Sosic www.srce.unizg.hr -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On 10/03/2012 08:38 PM, Aaron Russo wrote: Personally, I would have liked to see a separate repo for each version of puppet (so that users of 2.6.x, 2.7.x and 3.0.x could continue to receive the latest and greatest for their version). But I also don't have to manage the thing, so I respect that it didn't turn out this way. However, I think the method of communicating to the community can be improved to compensate. Yeah, this would be the best solution, to have different repositories for different subversions. I don't like the naming solution where puppet packages are named puppet2 or puppet3... -- Jakov Sosic www.srce.unizg.hr -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
Well, in many enterprise distro having different name and, possibly, no conflicting path for a complex package is a common option. In rhel5 for example exists samba package for samba 3.0.x and samba3x for samba 3.x , and samba it is often a critical package and the change between different versión are many and important. I believe that it is true also for puppet, and i think that should be a sysadmin's choice to upgrade to a new major version. And not everyone is so expert in dealing with yum repository, or apt fwiw. Best 2012/10/7, Jakov Sosic jso...@srce.hr: On 10/03/2012 08:38 PM, Aaron Russo wrote: Personally, I would have liked to see a separate repo for each version of puppet (so that users of 2.6.x, 2.7.x and 3.0.x could continue to receive the latest and greatest for their version). But I also don't have to manage the thing, so I respect that it didn't turn out this way. However, I think the method of communicating to the community can be improved to compensate. Yeah, this would be the best solution, to have different repositories for different subversions. I don't like the naming solution where puppet packages are named puppet2 or puppet3... -- Jakov Sosic www.srce.unizg.hr -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Inviato dal mio dispositivo mobile -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On 10/07/2012 07:30 PM, devzero2000 wrote: Well, in many enterprise distro having different name and, possibly, no conflicting path for a complex package is a common option. In rhel5 for example exists samba package for samba 3.0.x and samba3x for samba 3.x , and samba it is often a critical package and the change between different versión are many and important. I believe that it is true also for puppet, and i think that should be a sysadmin's choice to upgrade to a new major version. And not everyone is so expert in dealing with yum repository, or apt fwiw. I know for that practice, but the problem is that it makes upgrade from samba to samba3x packages a problem. So I would rather avoid that with the puppet. And if you know how to add puppetlabs repo to yum, then you'll know how to choose what version repo to use. Just take a look at postgresql repositories. -- Jakov Sosic www.srce.unizg.hr -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
I know for that practice, but the problem is that it makes upgrade from samba to samba3x packages a problem. So I would rather avoid that with the puppet. And if you know how to add puppetlabs repo to yum, then you'll know how to choose what version repo to use. Just take a look at postgresql repositories. I would very much like how to do that, as it seams to me that yum versionlock locks the current installed package from being upgraded, which is not really what we want =) We want that puppet-2.7.* and puppet-server-2.7.* can be upgraded. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/R5rn3iiiobMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
Hi Chad * Take a look at the yum versionlock plugin. My life has been much simpler since I deployed it. For a while I was excludeing puppet and friends in yum.conf, but that was a real pain. The versionlock plugin pins a package at the version you want, and then you can update when ready. When I do that I get # yum versionlock add puppet-server-2.7\* puppet-2.7\* # yum versionlock list Loaded plugins: fastestmirror, security, versionlock 0:puppet-server-2.7.19-1.el6.* 0:puppet-2.7.19-1.el6.* versionlock list done which I suppose will lock it to 2.7.19 and never to 2.7.20. Is it possible to lock it to 2.7.x ? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/MLdbBDAqqgYJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Wednesday, October 3, 2012 1:36:22 AM UTC+1, Michael Stanhke wrote: On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune je...@puppetlabs.comjavascript: wrote: On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.comjavascript: wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Not everyone subscribes to notices or reads the mailing lists regularly. Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. Yes. And users would expect to receive things like security updates and bug fixes fairly quickly. But a major upgrade than can break existing infrastructure should not have the same distribution name. It means that users who aren't ready to upgrade cannot use yum--- they will have to manually install updates to 2.7 because there will always be a newer v3 (unless you decide to create a separate distribution name for puppet 2.7, so that users can track that instead). I maintain a network that uses a non-standard Puppet installation (where manifests are distributed using git hooks instead of using a Puppet master). So my concerns about a major upgrade are that much greater. I should add that I work for a small company that chose Puppet because we don't want to use large amounts of our time with system administration. So releasing a major upgrade in this manner negates that reason. Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you Under what project should the issue be filed? describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. Hope this helps, -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet...@googlegroups.comjavascript:. To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/XKCXN15MfqMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On 2 Oct 2012, at 21:17, Robert Rothenberg wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? I noticed this this morning as well, that some of my new cloud boxe installed puppet client 3, I'm also currently wondering if this is going to affect my new builds ... -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/o33U4atSmJwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote: On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune je...@puppetlabs.comjavascript: wrote: On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.comjavascript: wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series. It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended. The customary way to handle dual lines of packages is to give one line a different name, for example puppet3-* instead of plain puppet-*. Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being. If that's the plan then the first puppet2-* packages should have been released at the same time that the mainline packages were updated to v 3.0. Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases. Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 *will* cause breakage for users. PL, I urge you to reconsider. Soon. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/AG4SVCmBV1cJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound. So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks. - RIlindo On Oct 3, 2012, at 8:16 AM, jcbollinger john.bollin...@stjude.org wrote: I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series. It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended. The customary way to handle dual lines of packages is to give one line a different name, for example puppet3-* instead of plain puppet-*. Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being. If that's the plan then the first puppet2-* packages should have been released at the same time that the mainline packages were updated to v 3.0. Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases. Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 will cause breakage for users. PL, I urge you to reconsider. Soon. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/AG4SVCmBV1cJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
- Original Message - From: Rilindo Foster rili...@mac.com To: puppet-users@googlegroups.com Sent: Wednesday, October 3, 2012 3:02:58 PM Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound. So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks. +100, people seem to be expecting the rest of the world to maintain a controlled environment simply because they don't? Do you really trust a random third party as the source of your packages? What if there is an outage at one of these 3rd party package providers and you cannot build new machines? How do you explain that on the day that you suddenly need to scale your infrastructure due to a critical request or failure? You have to build local repo mirrors and you have to be able to recover from a disaster or simply provision new infrastructure based on your own processes and systems you influence, if you do not you have bigger problems than what version of Puppet is on some 3rd party repo. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On 3 October 2012 15:02, Rilindo Foster rili...@mac.com wrote: I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound. So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks. I'm partially pissed of with PL as well, and I'm really not liking the responses that say, well you should manage the package versions you have installed To me, the point is here, that this is more of a case of BAD repo managment. It's NOT the same package, AND it doesn't have full 100% backward compatibility - So it's a DIFFERENT package - give it a new name. Also, those gloating that manage their packages using version numbers, and are not affected by this - YOU ARE NOT HELPING. The problem is HOW the package was pushed out, not the fact that it was pushed out. Also, puppet v2 is also going to be available still - If it was me, I would have created a meta package called puppet, and 'linked' that puppet 2, and called puppet3, puppet 3. I'd also create a package called puppet2. And about 6 weeks after release, upgrade meta package puppet to puppet 3. -- I'm just saying :) - RIlindo On Oct 3, 2012, at 8:16 AM, jcbollinger john.bollin...@stjude.org wrote: I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series. It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended. The customary way to handle dual lines of packages is to give one line a different name, for example puppet3-* instead of plain puppet-*. Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being. If that's the plan then the first puppet2-* packages should have been released at the same time that the mainline packages were updated to v 3.0. Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases. Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 *will* cause breakage for users. PL, I urge you to reconsider. Soon. John Agreed + 101 (looks at RIP) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
I agree that folks should manage their repos, but I wanted to throw in a couple of thoughts: * The package name hacks (eg puppet3) are usually done by distributions to allow multiple versions of software to co-exist. * Take a look at the yum versionlock plugin. My life has been much simpler since I deployed it. For a while I was excludeing puppet and friends in yum.conf, but that was a real pain. The versionlock plugin pins a package at the version you want, and then you can update when ready. - Chad On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger john.bollin...@stjude.org wrote: On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote: On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune je...@puppetlabs.com wrote: On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.com wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series. It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended. The customary way to handle dual lines of packages is to give one line a different name, for example puppet3-* instead of plain puppet-*. Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being. If that's the plan then the first puppet2-* packages should have been released at the same time that the mainline packages were updated to v 3.0. Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases. Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 will cause breakage for users. PL, I urge you to reconsider. Soon. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/AG4SVCmBV1cJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Chad M. Huneycutt -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On 3 October 2012 15:51, Chad Huneycutt chad.huneyc...@gmail.com wrote: I agree that folks should manage their repos, but I wanted to throw in a couple of thoughts: * The package name hacks (eg puppet3) are usually done by distributions to allow multiple versions of software to co-exist. I think that we have the requirements for the package name hack, as in 2 separate package versions * Take a look at the yum versionlock plugin. My life has been much simpler since I deployed it. For a while I was excludeing puppet and friends in yum.conf, but that was a real pain. The versionlock plugin pins a package at the version you want, and then you can update when ready. I will take a look at this plugin when I have a moment, thanks for the tip - Chad On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger john.bollin...@stjude.org wrote: On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote: On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune je...@puppetlabs.com wrote: On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.com wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series. It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended. The customary way to handle dual lines of packages is to give one line a different name, for example puppet3-* instead of plain puppet-*. Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being. If that's the plan then the first puppet2-* packages should have been released at the same time that the mainline packages were updated to v 3.0. Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases. Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 will cause breakage for users. PL, I urge you to reconsider. Soon. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/AG4SVCmBV1cJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Chad M. Huneycutt -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
It might be worth an enhancement request to have Package: ensure = version call yum versionlock or zypper add-lock if they are present On Oct 3, 2012 10:55 AM, Mister Guru misteritg...@gmail.com wrote: On 3 October 2012 15:51, Chad Huneycutt chad.huneyc...@gmail.com wrote: I agree that folks should manage their repos, but I wanted to throw in a couple of thoughts: * The package name hacks (eg puppet3) are usually done by distributions to allow multiple versions of software to co-exist. I think that we have the requirements for the package name hack, as in 2 separate package versions * Take a look at the yum versionlock plugin. My life has been much simpler since I deployed it. For a while I was excludeing puppet and friends in yum.conf, but that was a real pain. The versionlock plugin pins a package at the version you want, and then you can update when ready. I will take a look at this plugin when I have a moment, thanks for the tip - Chad On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger john.bollin...@stjude.org wrote: On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote: On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune je...@puppetlabs.com wrote: On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.com wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series. It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended. The customary way to handle dual lines of packages is to give one line a different name, for example puppet3-* instead of plain puppet-*. Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being. If that's the plan then the first puppet2-* packages should have been released at the same time that the mainline packages were updated to v 3.0. Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases. Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 will cause breakage for users. PL, I urge you to reconsider. Soon. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/AG4SVCmBV1cJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Chad M. Huneycutt -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Wednesday, October 3, 2012 3:51:28 PM UTC+1, Chad Huneycutt wrote: I agree that folks should manage their repos, but I wanted to throw in a couple of thoughts: * The package name hacks (eg puppet3) are usually done by distributions to allow multiple versions of software to co-exist. No. The puppet2 and puppet3 packages can be marked as mutually exclusive. * Take a look at the yum versionlock plugin. My life has been much simpler since I deployed it. For a while I was excludeing puppet and friends in yum.conf, but that was a real pain. The versionlock plugin pins a package at the version you want, and then you can update when ready. The problem I have is in deploying new VMs with Cobbler. The versionlock plugin does not work for deploying new machines, and unfortunately, Cobbler's package exclusion doesn't work either. - Chad On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger john.bo...@stjude.orgjavascript: wrote: On Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke wrote: On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune je...@puppetlabs.com wrote: On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.com wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series. It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended. The customary way to handle dual lines of packages is to give one line a different name, for example puppet3-* instead of plain puppet-*. Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being. If that's the plan then the first puppet2-* packages should have been released at the same time that the mainline packages were updated to v 3.0. Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases. Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 will cause breakage for users. PL, I urge you to reconsider. Soon. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/AG4SVCmBV1cJ. To post to this group, send email to puppet...@googlegroups.comjavascript:. To unsubscribe from this group, send email to puppet-users...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Chad M. Huneycutt -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ohWv88bzTbYJ. To post to this group, send email to
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
+1 On Wed, Oct 3, 2012 at 9:02 AM, Rilindo Foster rili...@mac.com wrote: I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound. So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
full disclosure: I don't use the puppetlabs repos. Below are just some observations and concerns I wanted to voice. On Tue, Oct 2, 2012 at 5:36 PM, Michael Stahnke stah...@puppetlabs.comwrote: On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune j...@puppetlabs.com wrote: On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.com wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. Where was this announced? On the list? Not everyone who follows the official install instructions ( http://docs.puppetlabs.com/guides/installation.html) is cool enough to join the mailing list :-P The real problem, IMHO, is there is no clear policy regarding the PuppetLabs repo (or at least none I could find easily). These repos contain the latest available packages for Puppet, ... is somewhat ambiguous (or maybe its just me) -- does that mean the latest of the current release or the latest version overall? We now know it's the latter. To that affect, I think it would benefit the community if there was a clearly defined policy with respect to the repos, much like EPEL does ( http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies). The closest thing I found was ( http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html), which I don't think is adequate to describe the intention of the repos. Second-to-lastly, my biggest concern with this problem in its current state, is the potential fallout of users (and the people they influence) who now find puppet to be too volatile or too unstable, and decide to look for alternatives. I won't argue against that these users should have had better practices to prevent this, because it doesn't change the fact that these people are still put off. Personally, I would have liked to see a separate repo for each version of puppet (so that users of 2.6.x, 2.7.x and 3.0.x could continue to receive the latest and greatest for their version). But I also don't have to manage the thing, so I respect that it didn't turn out this way. However, I think the method of communicating to the community can be improved to compensate. And finally, thanks for all the work guys. Puppet is a fantastic product, and has a fantastic community behind it. Cheers, Aaron Russo Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. Hope this helps, -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote: - Original Message - From: Rilindo Foster ril...@mac.com javascript: To: puppet...@googlegroups.com javascript: Sent: Wednesday, October 3, 2012 3:02:58 PM Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound. So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks. +100, people seem to be expecting the rest of the world to maintain a controlled environment simply because they don't? Do you really trust a random third party as the source of your packages? What if there is an outage at one of these 3rd party package providers and you cannot build new machines? How do you explain that on the day that you suddenly need to scale your infrastructure due to a critical request or failure? You have to build local repo mirrors and you have to be able to recover from a disaster or simply provision new infrastructure based on your own processes and systems you influence, if you do not you have bigger problems than what version of Puppet is on some 3rd party repo. Of course it is ultimately my responsibility which versions of which packages get installed on my systems, from which repositories. Of course it is in my best interest to ensure package availability if that's important to me. Indeed, I do maintain local mirrors of the repositories I depend on. All of that is beside the point. Personally, I expect package repository managers to make a best effort at maintaining a managed environment *because I perceive that as an implicit promise that repository management makes to clients* by virtue of providing a public repository in the first place. Whether that perception is reasonable is also not the point, but the fact that it seems to be shared by a a substantial number of users should certainly trigger an alarm at PL HQ. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/NnjAVc7q3QUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
- Original Message - From: R.I.Pienaar r...@devco.net To: puppet-users@googlegroups.com Sent: Wednesday, October 3, 2012 8:25:52 PM Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo - Original Message - From: jcbollinger john.bollin...@stjude.org To: puppet-users@googlegroups.com Sent: Wednesday, October 3, 2012 8:20:38 PM Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote: - Original Message - From: Rilindo Foster ril...@mac.com To: puppet...@googlegroups.com Sent: Wednesday, October 3, 2012 3:02:58 PM Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound. So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks. +100, people seem to be expecting the rest of the world to maintain a controlled environment simply because they don't? Do you really trust a random third party as the source of your packages? What if there is an outage at one of these 3rd party package providers and you cannot build new machines? How do you explain that on the day that you suddenly need to scale your infrastructure due to a critical request or failure? You have to build local repo mirrors and you have to be able to recover from a disaster or simply provision new infrastructure based on your own processes and systems you influence, if you do not you have bigger problems than what version of Puppet is on some 3rd party repo. Of course it is ultimately my responsibility which versions of which packages get installed on my systems, from which repositories. Of course it is in my best interest to ensure package availability if that's important to me. Indeed, I do maintain local mirrors of the repositories I depend on. All of that is beside the point. Personally, I expect package repository managers to make a best effort at maintaining a managed environment because I perceive that as an implicit promise that repository management makes to clients by virtue of providing a public repository in the first place. Whether that perception is reasonable is also not the point, but the fact that it seems to be shared by a a substantial number of users should certainly trigger an alarm at PL HQ. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/NnjAVc7q3QUJ . To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote: - Original Message - From: Rilindo Foster ril...@mac.com javascript: To: puppet...@googlegroups.com javascript: Sent: Wednesday, October 3, 2012 3:02:58 PM Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound. So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks. +100, people seem to be expecting the rest of the world to maintain a controlled environment simply because they don't? Do you really trust a random third party as the source of your packages? What if there is an outage at one of these 3rd party package providers and you cannot build new machines? How do you explain that on the day that you suddenly need to scale your infrastructure due to a critical request or failure? You have to build local repo mirrors and you have to be able to recover from a disaster or simply provision new infrastructure based on your own processes and systems you influence, if you do not you have bigger problems than what version of Puppet is on some 3rd party repo. Of course it is ultimately my responsibility which versions of which packages get installed on my
[Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/o33U4atSmJwJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.com wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. Hope this helps, -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune j...@puppetlabs.com wrote: On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg rob...@gmail.com wrote: I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. Hope this helps, -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
