I for one would love to feel more safe when tempting fate upgrading my puppet infrastructure. I like the idea of rolling upgrades (if upgraded, point here), but i would love to have some sort of process in puppet to handle this. A configuration/feature flag that says "hey puppet, we're upgrading, lets converge". Have some sort of orchestration/reporting capability in this migration state (a light convergence catalog - hey, my file service in upgrade mode is only serving new agent code and if i see you have new agent code, converge to new master and call home)
MCollective does make things slightly easier/more flexible in this regard but i hardly come across many people using it. i'm mostly thinking out loud remembering my last big upgrading but kicking myself for not writing down my wishlist -byron On Friday, November 14, 2014 12:16:07 PM UTC-6, Felix Frank wrote: > > On 11/14/2014 07:09 PM, Henrik Lindberg wrote: > > > > Please note that some changes in puppet 4 mean that puppet 3 agents > > won’t be able to talk to puppet 4 masters (or vice-versa). This probably > > means you don’t want to be updating puppet itself with “ensure => > latest” :) > > > > Hi, > > point taken, but what will the update plan look like for a large > installation? Will users be required to incorporate MCollective or > similar to be able to upgrade their agents? > > Or should they try making all their agents update themselves until each > last one won't talk to the master again, which can then be "safely" > updated. > > The latter will not fly. > > Cheers, > Felix > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/f61bfb41-8748-47f7-bb27-91d09f140301%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
