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.
