On Mon, Nov 17, 2014 at 6:22 AM, Byron Miller <byr...@gmail.com> wrote:
> 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)
>
What I'd been thinking (pretty much the same as what Erik said) is that
you'd do something like this:
1. Set up a new Puppet 4 master (alongside your Puppet 3 master, as opposed
to replacing it).
2. Have a module with a class in it called "puppet4::agent"; it requires a
parameter called "puppet4_server", and the implementation of the class is
to basically do "package {'puppet': ensure => 4.0 } -> ini_setting
{'puppet4_server': file => 'puppet.conf', section => 'agent', setting =>
'server', value => $puppet4_server }".
3. You add this class to the classification of the nodes in your fleet at
whatever cadence makes sense for you.
I'd like to play around with step 2 there and prove that out a bit more,
but it seems like it should work. Also, since Puppet 4 will have the
future parser enabled by default, it seems like it would be highly
desirable to move nodes over from 3 to 4 a few at a time and very
deliberately, just to make sure that the language changes don't break your
existing manifests. This strategy would encourage that approach over the
more risky approach of simply trying to upgrade your whole fleet all at
once.
We were also batting around the idea of possibly putting the puppet4
packages in separate yum/apt repos from the puppet3 packages, so that
ensure=>latest wouldn't catch anyone by surprise. We haven't talked
through this in much detail yet (I recall that there was a spirited debate
around this idea when we bumped from puppet2 to puppet3), so I don't know
if it has any legs, but it did come up as an idea.
--
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/CAMx1QfLEx40bF%2B_y9fPRacD8_TxRUuCt3iYeP9KYTD-1z7o%3D2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
