Puppet version bump
antarus at google.com
Tue Feb 5 19:09:19 UTC 2013
On Tue, Feb 5, 2013 at 10:07 AM, John Moser <john.r.moser at gmail.com> wrote:
> On Tue, Feb 5, 2013 at 12:55 PM, Alec Warner <antarus at google.com> wrote:
>> On Tue, Feb 5, 2013 at 4:52 AM, Robie Basak <robie.basak at canonical.com> wrote:
>> > On Sun, Jan 27, 2013 at 11:23:37AM -0500, John Moser wrote:
>> >> OK further research yields that Debian is not updating Sid due to
>> >> Can we see this imported to 13.04?
>> > What would the implications be of an update to puppet 3 in the archive
>> > for installations using older LTS releases running older versions of
>> > puppet? Can an agent continue to run 2.7 and be served by a 3
>> > puppetmaster?
>> As long as the server version is >= the client version, things are OK.
>> If the client version is > the server version, things can go wrong
>> very quickly. 'Wrong' tends to mean 'clients will fail to get
> This is correct and important.
>> > I'm just trying to identify if there are any cases where it could be
>> > painful for users to find that puppet has been updated, for any
>> > reasonable upgrade path. Are there any complications that I haven't
>> > thought of, or would everything be fine?
>> I run puppet on thousands of nodes. If you updated puppet in the
>> middle of an LTS; I would be *pissed* as all hell.
> Yes and I am absolutely *not* recommending they update the LTS.
> I'm recommending the latest up-and-coming release of Ubuntu get the
> new Puppet. If you want to continue using an LTS with Puppet, you
> have three choices:
> 1. Keep your shop LTS. When a new LTS comes out, upgrade your
> Puppetmaster FIRST (after all staging of course), then roll out the
> LTS updates to the clients.
> 2. Convince Ubuntu to put the newest Puppetmaster in Backports. I am
> not advocating this either.
> 3. Use the Puppetlabs repos on your LTS Puppetmaster
> I have no sympathy for the use case of running your Puppetmaster as
> LTS and expecting the next five years of Ubuntu releases to hold back
> updating Puppet just so you can mix and match LTS server with
> latest-release clients. Among other things, this would cause an issue
> where overlapping LTS (i.e. 3 years between) would require the new LTS
> stay on the old Puppet, which means that Puppet never gets upgraded
> since there is always an in-life LTS holding back Puppet for all
> further releases when a new LTS comes out.
I don't think any sane customers expect this (and I do not.) Letter
updates (P -> Q, Q -> R) are when I expect changes (and pain!) But
that is why we are on a release based OS and not a rolling release
like Arch ;)
> I do have sympathy for the use case of staying on an LTS for the whole
> network. If you use LTS Puppetmaster to administrate LTS servers,
> this should not break. Mind you if an update to Puppet comes down to
> the LTS, the Puppetmaster will update; but maybe you don't WANT to
> move forward--that's why you're on LTS. Yes I understand this use
> case and yes it is problematic in many ways, but it can be handled
> stably at the discretion of the administrator--it's up to you to
> decide to update your server to a newer version, move to a newer
> Puppetmaster, update your modules and other Puppet code to work with
> the newest Puppetmaster, and then perform your roll-outs. We don't
> need to throw down "HERE IS PUPPET 3.1 FOR LTS ENJOY YOUR BREAKAGE" at
> My advice to you: If your LTS Puppetmaster isn't going to handle
> Puppet 3.0 or 3.1 clients, don't upgrade your administrated servers to
> Raring. Wait for the next LTS; go Puppetlabs repos; or upgrade your
> Puppetmaster to Raring first.
>> > Robie
>> > --
>> > Ubuntu-devel-discuss mailing list
>> > Ubuntu-devel-discuss at lists.ubuntu.com
>> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
More information about the Ubuntu-devel-discuss