Re: Puppet version bump
On 02/05/2013 06:45 PM, Ryan Tandy wrote: > John Moser gmail.com> writes: >> 2. Convince Ubuntu to put the newest Puppetmaster in Backports. I am >> not advocating this either. > Slightly off-topic, but FWIW I would be happy to see raring's puppet > (whatever version that ends up being) in precise-backports. > lucid-backports has puppet 2.7 and that made my life a LOT easier since > my puppetmaster runs precise and I am using some recent modules. Having > backports available but not installed by default is really quite nice. > Furthermore it's quite likely that at some point I'll have some clients > running a newer Ubuntu than the puppetmaster, and it would be great to > be able to support it just by upgrading puppetmaster to a backports > version. > > If someone does the testing, I'm happy to keep pushing puppet updates to the backports repo. You can use the requestbackport script in ubuntu-dev-tools to file the request and list the testing needed. Thanks, Micah -- 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
Re: Puppet version bump
On 02/05/2013 07:58 PM, Alec Warner wrote: On Tue, Feb 5, 2013 at 4:50 PM, John Moser wrote: On 02/05/2013 07:45 PM, Ryan Tandy wrote: John Moser gmail.com> writes: 2. Convince Ubuntu to put the newest Puppetmaster in Backports. I am not advocating this either. Slightly off-topic, but FWIW I would be happy to see raring's puppet (whatever version that ends up being) in precise-backports. lucid-backports has puppet 2.7 and that made my life a LOT easier since my puppetmaster runs precise and I am using some recent modules. Having backports available but not installed by default is really quite nice. Furthermore it's quite likely that at some point I'll have some clients running a newer Ubuntu than the puppetmaster, and it would be great to be able to support it just by upgrading puppetmaster to a backports version. http://apt.puppetlabs.com/ While we're at it, why is etckeeper stuff in the package? The Puppetlabs guys said because it's in Debian's package and "Debian packagers are fruitbats", so they're imitating "for compatibility." I know Nigel Kirsten and Andrew Pollock, so if there is stuff wrong in the debian packaging I am happy to chat with them. I'm just relaying what I got from #puppet on freenode. There seems to be no purpose to hooking etckeeper--at least, none that warrants hooking it into puppet by default. -A -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 4:50 PM, John Moser wrote: > > > On 02/05/2013 07:45 PM, Ryan Tandy wrote: >> >> John Moser gmail.com> writes: >>> >>> 2. Convince Ubuntu to put the newest Puppetmaster in Backports. I am >>> not advocating this either. >> >> >> Slightly off-topic, but FWIW I would be happy to see raring's puppet >> (whatever version that ends up being) in precise-backports. >> lucid-backports has puppet 2.7 and that made my life a LOT easier since >> my puppetmaster runs precise and I am using some recent modules. Having >> backports available but not installed by default is really quite nice. >> Furthermore it's quite likely that at some point I'll have some clients >> running a newer Ubuntu than the puppetmaster, and it would be great to >> be able to support it just by upgrading puppetmaster to a backports >> version. >> >> > > http://apt.puppetlabs.com/ > > While we're at it, why is etckeeper stuff in the package? The Puppetlabs > guys said because it's in Debian's package and "Debian packagers are > fruitbats", so they're imitating "for compatibility." I know Nigel Kirsten and Andrew Pollock, so if there is stuff wrong in the debian packaging I am happy to chat with them. -A > > > -- > 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
Re: Puppet version bump
On 02/05/2013 07:45 PM, Ryan Tandy wrote: John Moser gmail.com> writes: 2. Convince Ubuntu to put the newest Puppetmaster in Backports. I am not advocating this either. Slightly off-topic, but FWIW I would be happy to see raring's puppet (whatever version that ends up being) in precise-backports. lucid-backports has puppet 2.7 and that made my life a LOT easier since my puppetmaster runs precise and I am using some recent modules. Having backports available but not installed by default is really quite nice. Furthermore it's quite likely that at some point I'll have some clients running a newer Ubuntu than the puppetmaster, and it would be great to be able to support it just by upgrading puppetmaster to a backports version. http://apt.puppetlabs.com/ While we're at it, why is etckeeper stuff in the package? The Puppetlabs guys said because it's in Debian's package and "Debian packagers are fruitbats", so they're imitating "for compatibility." -- 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
Re: Puppet version bump
John Moser gmail.com> writes: > 2. Convince Ubuntu to put the newest Puppetmaster in Backports. I am > not advocating this either. Slightly off-topic, but FWIW I would be happy to see raring's puppet (whatever version that ends up being) in precise-backports. lucid-backports has puppet 2.7 and that made my life a LOT easier since my puppetmaster runs precise and I am using some recent modules. Having backports available but not installed by default is really quite nice. Furthermore it's quite likely that at some point I'll have some clients running a newer Ubuntu than the puppetmaster, and it would be great to be able to support it just by upgrading puppetmaster to a backports version. -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 4:16 PM, Alec Warner wrote: > Last time I checked, it took a human to actually dist-upgrade (to go > from 2.7 to 3.0...) What you expect and what everybody and their mother does are two different things. > Are people really doing that and not expecting things to go horribly wrong? :) You wouldn't believe how many people I've seen do it and expect nothing to go wrong just because they hear Ubuntu is easy, just because they hear that Ubuntu has tools to help you upgrade, just because they hear this and that they expect the case to be perfect upgrade. I'm not talking about people I directly work with, I'm talking about clients. -- 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
Re: kexec and Grub
John Moser composed: Kexec ... Nobody uses it. Only rather recently did openSUSE stop using it by default to first-boot a newly installed system. Maybe a look at how this was done would be helpful. On 2013-02-05 16:58 (GMT-0500) John Moser composed: ... SOLUTION B: - Load Grub into kexec - Shut down the system into a halt state and call kexec as your termination (halt, reboot, etc) command Which of these looks easier? You have no system you can test both on, or lack time prior to the critical hour? Given how core.img works, I vote B. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 1:24 PM, Jordon Bedwell wrote: > On Tue, Feb 5, 2013 at 3:09 PM, John Moser wrote: >> I work in a place without staging, and we desperately need it, and I >> am becoming slowly more aggressive and will be making arguments after >> I torch my burn down charts. >> >> Think about that though. No testing environment. So much pain. > > Talk about loving to live on the dangerous and wild side :P > >> With a testing environment, massive breakage to me is just a >> playground and casual Friday. > > Oddly enough I kinda feel like your sentence says. When I see people > upgrade without staging I get this fire rage and I hate everything > about what's broken and I'm angry for days after fixing it and I'm > angry I have to figure out what broke and I'm just angry at the world > at that point but when proper staging happens, oddly enough I don't > care at all and I'm more than happy to figure out what broke, it's > just like you said, it's like a casual Friday "yay I get to learn > something new." Last time I checked, it took a human to actually dist-upgrade (to go from 2.7 to 3.0...) Are people really doing that and not expecting things to go horribly wrong? :) -A -- 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
Re: kexec and Grub
On Tue, Feb 5, 2013 at 4:44 PM, Felix Miata wrote: > On 2013-02-05 16:07 (GMT-0500) John Moser composed: > > >> Has anyone gotten Grub2 to load via Linux Kexec? It used to be >> possible to kexec grub.exe for some reason. > > > This question makes me think either you haven't read the kexec man page, or > one of misunderstands it. Why need any bootloader be involved with kexec > usage? Oh I understand it. Just jumping straight to the bootloader is a desirable use case. Also covered in my message, you are less error prone going through the bootloader. Consider these two possible paths to solve the above problem: SOLUTION A: - Write yourself a Grub parser (maybe even something that runs grub itself and gets it to spit out a list of boot options, a select boot option, or the default boot option) - Parse the data you get into viable arguments to pass to kexec for loading the kernel, initrd, setting parameters, etc. - Shut down the system to a halt state and call kexec as your termination (halt, reboot, etc) command. SOLUTION B: - Load Grub into kexec - Shut down the system into a halt state and call kexec as your termination (halt, reboot, etc) command Which of these looks easier? -- 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
Re: kexec and Grub
On 2013-02-05 16:07 (GMT-0500) John Moser composed: Has anyone gotten Grub2 to load via Linux Kexec? It used to be possible to kexec grub.exe for some reason. This question makes me think either you haven't read the kexec man page, or one of misunderstands it. Why need any bootloader be involved with kexec usage? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 3:09 PM, John Moser wrote: > I work in a place without staging, and we desperately need it, and I > am becoming slowly more aggressive and will be making arguments after > I torch my burn down charts. > > Think about that though. No testing environment. So much pain. Talk about loving to live on the dangerous and wild side :P > With a testing environment, massive breakage to me is just a > playground and casual Friday. Oddly enough I kinda feel like your sentence says. When I see people upgrade without staging I get this fire rage and I hate everything about what's broken and I'm angry for days after fixing it and I'm angry I have to figure out what broke and I'm just angry at the world at that point but when proper staging happens, oddly enough I don't care at all and I'm more than happy to figure out what broke, it's just like you said, it's like a casual Friday "yay I get to learn something new." -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 4:07 PM, Jordon Bedwell wrote: > On Tue, Feb 5, 2013 at 3:00 PM, John Moser wrote: >> On a related note, Puppet 3.1 came out ... yesterday. So next debate: >> 3.0.2 or 3.1 into Debian experimental? (I've been trying to get it >> brought in) > > If it were me, I would rather fight to upgrade once, not twice. > >> 3.1 did not include https://projects.puppetlabs.com/issues/16856 or I >> would be lobbying heavily for 3.1 into Experimental and then directly >> into Ubuntu. As is, there are good arguments for sticking to 3.0.2 in >> this scenario (notably: stuff was deprecated in 3.0; it is GONE in >> 3.1, and now Ubuntu/Debian have to make a jump since next Stable will >> be 2.7 for Debian and the last was 2.7 for Ubuntu. The 2.7 -> 3.1 >> jump is nasty). > > Exactly my point, I would rather fight once to upgrade then fight once > to upgrade then have to fight again to figure out what hell broke in > the next upgrade though most of the time it can be somewhat straight > forward if treading carefully. I'd rather it all fall down at once > during a test-run and it be fixed than me have to do those runs twice > in the same year. I work in a place without staging, and we desperately need it, and I am becoming slowly more aggressive and will be making arguments after I torch my burn down charts. Think about that though. No testing environment. So much pain. With a testing environment, massive breakage to me is just a playground and casual Friday. -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 3:00 PM, John Moser wrote: > On a related note, Puppet 3.1 came out ... yesterday. So next debate: > 3.0.2 or 3.1 into Debian experimental? (I've been trying to get it > brought in) If it were me, I would rather fight to upgrade once, not twice. > 3.1 did not include https://projects.puppetlabs.com/issues/16856 or I > would be lobbying heavily for 3.1 into Experimental and then directly > into Ubuntu. As is, there are good arguments for sticking to 3.0.2 in > this scenario (notably: stuff was deprecated in 3.0; it is GONE in > 3.1, and now Ubuntu/Debian have to make a jump since next Stable will > be 2.7 for Debian and the last was 2.7 for Ubuntu. The 2.7 -> 3.1 > jump is nasty). Exactly my point, I would rather fight once to upgrade then fight once to upgrade then have to fight again to figure out what hell broke in the next upgrade though most of the time it can be somewhat straight forward if treading carefully. I'd rather it all fall down at once during a test-run and it be fixed than me have to do those runs twice in the same year. -- 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
kexec and Grub
Has anyone gotten Grub2 to load via Linux Kexec? It used to be possible to kexec grub.exe for some reason. I have been tasked tonight to reboot a very critical production server during a short window. It's long enough, but at the moment our big issue is that the reboot will be somewhere between 3-5 minutes up to 18 minutes (we don't know) because server hardware does a ton of self-check and has RAID, Video, bootrom, etc BIOS crap to go through. Years ago, this came up and Kexec was written. Nobody uses it. We use it for fancy debugging but that's it. So I propose: We must find a method of rebooting into A) a bootloader entry; or B) directly into Grub2 and let it boot the system. (B) would be less fragile, as any incorrectness in (A) will at best make kexec fail during late-stage shutdown and at worst load the kernel with invalid parameters and cause a panic before mounting rootfs (a nightmare without remote console). Loading the bootloader can only fail in general, in which case we can go as far as re-initializing init onto an operating runlevel and come back up without a reboot (white hot reboot). So: - Cold boot (physical power cycle) - Warm boot (ACPI reboot) - Red hot boot (drop back and reload the kernel/bootloader) - White hot boot (shutdown completely, then go back into a live runlevel rather than halt or reboot) We're attempting a red hot boot, and on soft failure coming out via a white hot boot. If Linux can respond to panic() by warm boot, that would be very optimal. (Spoiler: the next logical step would be porting freeze/thaw from Dragonfly so you can reboot into a new kernel without closing your desktop session. Yes, this is totally doable. You would not believe the insanity that is physically possible.) -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 2:09 PM, Alec Warner wrote: > On Tue, Feb 5, 2013 at 10:07 AM, John Moser wrote: >> 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 ;) > Oh good, then we're on the same page. On a related note, Puppet 3.1 came out ... yesterday. So next debate: 3.0.2 or 3.1 into Debian experimental? (I've been trying to get it brought in) 3.1 did not include https://projects.puppetlabs.com/issues/16856 or I would be lobbying heavily for 3.1 into Experimental and then directly into Ubuntu. As is, there are good arguments for sticking to 3.0.2 in this scenario (notably: stuff was deprecated in 3.0; it is GONE in 3.1, and now Ubuntu/Debian have to make a jump since next Stable will be 2.7 for Debian and the last was 2.7 for Ubuntu. The 2.7 -> 3.1 jump is nasty). Alec, I'm sure you can appreciate the implications, as well as the challenging difficulties now faced due to failure to keep up with a fast moving target. If it's that important, we may need to just throw down 3.0 and 3.1 and meta-packages for a while here. This is all kinds of badness, too: 3.0 is dead; 3.0.2 is the last and there will be no more updates to the branch (think Apple Quicktime, you know the drill), so we definitely don't want to support Puppet 3 for an extended time because no bugfixes. TBH, for Puppet in general, your task is to keep up; like Pacemaker, Corosync, and Heartbeat, Puppet is racing towards advancement and things are rapidly changing. You should see the mess that is Pacemaker/Corosync, trying with RHEL5 and RHEL6 and SuSE and Debian gets you many different procedures and different configurations required. It's now somewhat stabilized, and has grown into something awesome. Puppet is doing that right now and pain will come. -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 10:07 AM, John Moser wrote: > On Tue, Feb 5, 2013 at 12:55 PM, Alec Warner wrote: >> >> On Tue, Feb 5, 2013 at 4:52 AM, Robie Basak >> 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 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 > 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
Re: Puppet version bump
On Tue, Feb 05, 2013 at 09:55:30AM -0800, Alec Warner wrote: > > 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. I am talking about updates to the development version only, which would appear in the subsequent stable release. Stable releases (LTS or not) are not updated except for security updates and important bugs. This isn't even a decision that needs to be made. Doing otherwise would violate SRU policy (https://wiki.ubuntu.com/StableReleaseUpdates). -- 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 12:55 PM, Alec Warner wrote: > > On Tue, Feb 5, 2013 at 4:52 AM, Robie Basak 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
Re: Puppet version bump
On Tue, Feb 5, 2013 at 4:52 AM, Robie Basak 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 >> feature freeze for Testing. However, Mathisain notes this: >> >> On the other hand, the master packaging branch at >> http://anonscm.debian.org/gitweb/?p=pkg-puppet/puppet.git;a=summary >> yields a working set of puppet 3.0.2 debs, they're just not tagged with >> a debian release. Feel free to use that until we can upload to sid. >> >> 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? > > There is some documentation for this. > http://docs.puppetlabs.com/guides/upgrading.html says "Older agent nodes > can get catalogs from a newer puppet master. The inverse is not always > true.". So it sounds like it should be fine. If we provide puppet 3 in > 13.04, then providing that users upgrade their puppetmaster to 13.04, > then everything will work smoothly, right? 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'. > > 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. > > 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
Re: Puppet version bump
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 > feature freeze for Testing. However, Mathisain notes this: > > On the other hand, the master packaging branch at > http://anonscm.debian.org/gitweb/?p=pkg-puppet/puppet.git;a=summary > yields a working set of puppet 3.0.2 debs, they're just not tagged with > a debian release. Feel free to use that until we can upload to sid. > > 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? There is some documentation for this. http://docs.puppetlabs.com/guides/upgrading.html says "Older agent nodes can get catalogs from a newer puppet master. The inverse is not always true.". So it sounds like it should be fine. If we provide puppet 3 in 13.04, then providing that users upgrade their puppetmaster to 13.04, then everything will work smoothly, right? 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? 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
