[Puppet Users] Re: Prompting fact refresh from Puppet Event

donavan
Thu, 16 Dec 2010 08:40:36 -0000

On Dec 15, 6:46 am, Trevor Vaughan <tvaug...@onyxpoint.com>
wrote:
> Is is possible to spawn a puppet fact refresh from the completion of an
event?

Not that I know of. All of the clients facts are submitted as params
in the initial request for a catalog. There''s no client <=>
server
feedback loop during catalog compilation.

> The only thing that I could come up with is a custom fact that returns
> the architecture of the installed package and then adjust the path
> based on that.

Yes. That seems like the canonical way to do it.

> However, this takes *two* puppet runs to complete and I would like to
> get this down to one run by prompting a fact refresh after the package
> is installed.

Does it? I thought if you used pluginsync you had those facts
available when you requested the actual catalog. Should take just a
moment to test. Oh, you may be able to use subscribe/notify params to
signal Service[puppet] when your target package is installed. That
would force an immediate reload and run, giving you your fact for
sure.


Is this "3rd party" software installed/managed in the same puppet
catalog as your File[foo.comf]? If so you could get clever with
manifest evaluation order and try to inspect the already defined
Package:

class foo {
    include foo::application
    include foo::config
}
class foo::config {
    require(foo::package)
    if defined(Package[foo-x86_64]) or ($foo_fact == ''x86_64'')
{
        $foo_path = "lib64"
    } elsif defined(Package[foo-i686]) or ($foo_fact ==
''i686''){
        $foo_path = "lib"
    } else {
        fail("Could not detect a version of Package[foo]. This is
bad.")
    }
}

This is probably too clever by half though. And using defined() is
morally wrong 95% of the time. And I''m not positive that the require
will force the manifest eval order in your favor. But if it gets the
job done....