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) > 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) 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 > 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+unsubscr...@googlegroups.com. > For more options, visit this group at > 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 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.