I just did a 2.6.11 -> 2.7.12 migration with Puppet updating Puppet. The only real hitch I ran into was my puppet masters would update themselves but somehow Apache/Passenger didn't get restarted, so I had to do that by hand. Since I didn't start putting any 2.7 features into my manifests until *after* the 2.7 upgrade, the clients basically just upgraded themselves. And while I do have puppet running as a daemon, it's with no-schedule, and the "real" run happens out of cron. I think I'm actually going to kill off the daemon as it offers no benefit to me (and frequently wedged when I let it schedule updates). Doing it in cron allows me to meet externally imposed scheduling restrictions (no changes while production is running).
On Thu, Mar 29, 2012 at 10:42 PM, Ken Barber <k...@puppetlabs.com> wrote: > Hi Amos - its been a long long long time mate :-). > > > example for (1): Our vagrant (http://vagrantup.com/) dev base boxes > > still come with Puppet 2.6.3 while the manifest depends on Puppet 2.7 > > features. I can manually upgrade puppet manually (and that's what I do > > on dev), but when the time to deploy to production comes it > > practically means that I have to manually upgrade Puppet to 2.7 on all > > hosts before I push the change. > > You know - I've generally just used mcollective with the puppetral > plugin to do the Puppet agent RPM/deb upgrade in the case where the > client is the wrong version, and can now no longer interact with my > master: > > > http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentPackage > https://github.com/puppetlabs/mcollective-plugins/tree/master/agent/package > > At the end of the day, it uses the Puppet resource abstraction layer > anyway behind the scenes, only difference is that it is making the > change directly without the Puppet master interaction. But I can see > why you would want Puppet to just deal with this on its own. > > > 1. Provider exists but has to be updated. > > I could be mistaken about what I'm about to say, as I haven't > experimented with this new behaviour all that much. I wouldn't take my > word for it - so experiment and see :-). > > Surely the lazy evaluate solves this, I could be wrong - but if you > build up a relationship between the action that does the update - and > the provider that users that update then the update should occur > first. Then when the provider is evaluated lazily - all is well - it > has a new updated command/library/whatever? > > So: > > package { "daemontools": > ensure => "1.2.3", > } > Service { > require => Package["daemontools"] > } > > Is a rough way of doing it, but the default _is_ of course generic > here, and run stages may be a better solution - as its easier to have > your 'require's changed/overridden later on. (because defaults don't > stack with overrides). > > > 2. Puppet version update. > > Updating Puppet can be tricky, from an agent perspective if you run it > as a daemon there was a problem when updating to the recent Facter > 1.6.6 for example - as parts of Facter are loaded/evaluated > dynamically each (ie. the facts) - while others are loaded and cached > and never re-evaluated. This created a problem with I believe the ec2 > fact from memory - which started to use a library in facter/util/ec2 > (yes my fault). In that edge case you need to probably force a restart > of an agent after the package update really. Its crap I agree ... and > I'm all ears for a better solution/policy generally. > > From the master perspective - you can run into similar scenarios as > well. Generally speaking, the 'puppet managing puppet' case is always > hard mate. I always spend the most amount of time helping clients > 'manage' their puppetmaster with Puppet. And their are lots of > strategies here :-). > > What are you hitting that is problematic at the moment? Or what in > particular do you see? > > > 3. Configuration files - missing or have to be updated. > > Again, build up the dependencies using relationships in Puppet - as > per 1. Should work in a similar manner (from the description of the > new feature that is). > > > 4. Other types of configurations which have to take place, e.g. add a > > network link (e.g. VPN, proxy), > > Same again. > > > or make any other arbitrary change which can > > affect the rest of the puppet run (or future puppet runs). > > You might be getting into the 'manage the puppet case', again - > anything specific you expect? > > > What I'm thinking about is a generic way to say "OK, now I'm finished > doing > > all sorts of tweaks to the system, please start puppet and take these > tweaks > > into consideration". > > > > Is that possible? > > To be absolutely honest with you - up until now, this has been done > with pre-puppet stuff. That is - done with kickstart, jumpstart or > whatever you use to build the system. Of course, this then becomes > non-idempotent which makes Puppet less useful overall. > > Dude - try the lazy evaluate with the edge cases you've been seeing > and see how far you get - and lets discuss anything that still won't > work. We're really interested in solving this kind of chicken & egg > problems for good if we can. > > ken. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
