Thanks for the pointer, Gary. It seems to address the issue of missing providers, even better than my suggestion.
However, I'm not sure if/how it addresses other situations, e.g.: 1. Provider exists but has to be updated. 2. Puppet version update. 3. Configuration files - missing or have to be updated. 4. Other types of configurations which have to take place, e.g. add a network link (e.g. VPN, proxy), or make any other arbitrary change which can affect the rest of the puppet run (or future puppet runs). 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? Cheers, --Amos On Wednesday, March 21, 2012 1:51:48 PM UTC+11, Gary Larizza wrote: > > > > On Wed, Mar 21, 2012 at 1:11 PM, Amos Shapira <amos.shap...@gmail.com>wrote: > >> Hello, >> >> I encounter issues regarding puppet "self update" that I'm sure are >> not uncommon: >> 1. When puppet version updates it doesn't restart to run the rest of >> the manifest with the new version. >> 2. When a new provider is installed (or extra configuration is done to >> enable an existing provider), puppet still won't make it available. >> >> 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. >> >> example for (2): We use daemontools >> (http://cr.yp.to/daemontools.html<http://cr.yp.to/daemontools.html> >> ) >> to monitor some of our servers. Puppet comes with a "daemontools" >> Service type provider but since the daemontools package isn't >> installed yet the provider is made unavailable for the rest of the >> run. A second puppet run, assuming it managed to install daemontools >> in the first one before it failed on other things, succeeds in picking >> up the daemontools as a provider. >> >> another example for (2): I use opsview (https://github.com/dpeters/ >> puppet-opsview <https://github.com/dpeters/puppet-opsview>) to monitor >> hosts. When the type is loaded by puppet it >> looks for a file called /etc/puppet/opsview.conf to find URL/username/ >> password of the opsview REST server. This file doesn't exist (or can >> be out of date) in the first run causing the Type to fail. >> >> > Amos, have you seen this feature --> > http://projects.puppetlabs.com/issues/6907<http://projects.puppetlabs.com/issues/6907> > > > > >> My suggestion - >> >> Define a new "preload" stage - resources which can affect puppet's own >> execution (e.g. types, config files, puppet version updates) can be >> placed in that stage and eventually a specific function call (or a >> special built-in trigger inside the Puppet code?) will cause Puppet to >> drop everything at the end of this stage and start from fresh. >> >> The mechanism has to be careful to limit potential inifinite loops - >> e.g. if nothing was changed during the stage then don't re-run, or if >> the stage keeps changing things and puppet re-starts more than a set >> limit then fail. >> >> What do you think about this? Is there another solution/work-around/ >> standard-best-practice I'm not aware of? >> >> Thanks. >> >> -- >> 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+unsubscribe@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en> >> . >> >> > > > -- > > Gary Larizza > Professional Services Engineer > Puppet Labs > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/XUeixQ5zq7sJ. 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.
