I dont think there's a way to enforce this because you need to reload puppetd to activate the changes. If you use puppetrun you could distribute only the tag for your puppet module and restart the service. Hope this helps
On Fri, Feb 26, 2010 at 12:53 AM, Greg Retkowski <g...@rage.net> wrote: > Thanks! That sounds like the right way to do it! How to I ensure puppet > copies out a new puppet.conf with the changes before evaluating the class > that uses 'case "$customfact"'? > > Cheers, > > -- Greg > > Daniel wrote: >> >> Don't distribute your facter plugin via manifest. Use puppet's sync >> which is described her: >> http://reductivelabs.com/trac/puppet/wiki/PluginsInModules >> >> This will distribute your facter addons at the beginning of your run >> and you can use them in like any normal fact. >> >> On Thu, Feb 25, 2010 at 10:25 PM, Greg Retkowski <g...@rage.net> wrote: >> >>> >>> Hello Everyone, >>> I have a case where I'm depending on custom facter rules in my puppet >>> config, and those custom facter rules come from a ruby library that >>> puppet >>> installs. I need to know how I can ensure that library is installed by >>> puppet before classes that depend on those facts are evaluated.. >>> >>> To illustrate... >>> >>> class facter_rules { >>> file { >>> "/usr/lib/ruby/site_ruby/1.8/facter/custom.rb": >>> source => "puppet://$server/dist/custom.rb"; >>> } >>> } >>> >>> class sitestuff { >>> include facter_rules >>> case "$customfact" { >>> "value-a": { >>> # do stuff >>> } >>> "value-b": { >>> # do other stuff >>> } >>> } >>> } >>> ... >>> >>> Using this, often class sitestuff gets evaluated before my facter_rules >>> file >>> copy is done - which results in puppet exiting without putting custom.rb >>> in >>> place. I'm using puppet vers. 0.24.4. >>> >>> I've considered using 'before =>' in my facter_rules file definition, but >>> class 'sitestuff' may be defined or not defined depending on what >>> services/classes are defined on the host. >>> >>> Any ideas on how I can get around this chicken and egg problem? >>> >>> Cheers, >>> >>> -- Greg >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Users" group. >>> To post to this group, send email to puppet-us...@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-us...@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. > > -- Cheers, Daniel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
