On Tue, Feb 5, 2013 at 12:55 PM, Alec Warner <anta...@google.com> wrote: > > On Tue, Feb 5, 2013 at 4:52 AM, Robie Basak <robie.ba...@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 > updates'. >
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 people. 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@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@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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
