Puppet version bump
john.r.moser at gmail.com
Tue Feb 5 18:07:15 UTC 2013
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 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