On Jun 25, 2011, at 7:51 AM, Nigel Kersten wrote: > On Fri, Jun 24, 2011 at 4:28 PM, Craig White <craig.wh...@ttiltd.com> wrote: > >> 1. I want to require => >> /etc/puppet/modules/custom/lib/facter/$SOME_CUSTOM_FACT is actually executed >> and the fact is established before a particular package is >> installed/configured. I can't seem to find the proper syntax for requiring >> that fact first - before the attempted installation. > > If you're distributing facts as plugins in modules like this, the > pluginsync should cause the fact to be evaluated before the manifests > are parsed and the catalog is compiled. > > Something is going wrong if you're not getting your fact evaluated on > first run. You definitely have pluginsync on on the node? ---- Got this solved - custom facts syntax seems to be a little particular about 'exec' commands and apparently much prefers 'system' commands and that is why I was having issues getting it to run - fixed now. Yes, I had pluginsync on the node. ---- > >> 2. It seems that the custom/lib/facter directory is a bit squirrelly in that >> it gags on the automatic backup files created by emacs (FILENAME.rb~) and if >> I create a resource that depends upon a fact, the resource installation >> fails and the fact is never established when I was sort of expecting facter >> to run at the outset of any agent activity. > > Best practice in my opinion is to have all this in version control, > and have your version control system ignore all such backup files, but > it might be worth reporting a feature request to automatically exclude > the common text editor backup files. ---- OK - starting up doesn't always involve best practices ;-) In my case, I am racing to get up to a certain point and working with multiple VMWare images as my test bed and thus working full-time in a production mode and delaying the inevitable switch over to SVN and development & test modes. But I am sure that the issue will still remain in 'development' and 'test' modes if I actively edit in 'lib' directories instead of on my own desktop and commit via SVN.
This does however leave the last remaining chicken or the egg issue however and that is if I change the version in my passenger gem setup, it would take 2 separate runs of puppet agent... the first one to update the passenger gem and the next one to discover that 'fact' before the changes are implemented into the nginx & apache templates. I suppose I can leave this messy for now unless someone has a methodology that I can syntactically require the custom 'fact' to be applied immediately after the gem is updated but before the apache & nginx 'configure.pp' is 'notified' by passenger.pp. Thanks Craig -- 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.
