Trevor Vaughan
2010-Dec-15 14:46 UTC
[Puppet Users] Prompting fact refresh from Puppet Event
Is is possible to spawn a puppet fact refresh from the completion of an event? Here''s the scenario: 64-bit system, either a 64 or 32 bit application ''foo'' could be installed. If the 64 bit version is installed, foo.conf needs to be configured with a prepended lib64 path. If not, then the 32bit default is fine. 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. 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 anyone have any suggestions/techniques? Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Felix Frank
2010-Dec-15 15:12 UTC
Re: [Puppet Users] Prompting fact refresh from Puppet Event
On 12/15/2010 03:46 PM, Trevor Vaughan wrote:> Is is possible to spawn a puppet fact refresh from the completion of an event? > > Here''s the scenario: > > 64-bit system, either a 64 or 32 bit application ''foo'' could be installed. > > If the 64 bit version is installed, foo.conf needs to be configured > with a prepended lib64 path. If not, then the 32bit default is fine. > > 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. > > 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 anyone have any suggestions/techniques?Hrm, your manifest should be able to handle this one on its own. Assuming your foo.conf file is part of the foo::config class, add this subclass: foo::config::arch64bit { File["/etc/foo.conf"] { source => "..." } } Then, at the place in the manifest where you pick the 64bit version of the foo application, add an "include foo::config::arch64bit". Will this work for your manifest? Cheers, Felix -- 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. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Trevor Vaughan
2010-Dec-16 03:53 UTC
Re: [Puppet Users] Prompting fact refresh from Puppet Event
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No, because I''m not picking the 64 bit version. Someone else is picking the version and I have to figure out what it is and "do the right thing", making for extra fun times. Thanks though, Trevor On 12/15/2010 10:12 AM, Felix Frank wrote:> On 12/15/2010 03:46 PM, Trevor Vaughan wrote: >> Is is possible to spawn a puppet fact refresh from the completion of an event? >> >> Here''s the scenario: >> >> 64-bit system, either a 64 or 32 bit application ''foo'' could be installed. >> >> If the 64 bit version is installed, foo.conf needs to be configured >> with a prepended lib64 path. If not, then the 32bit default is fine. >> >> 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. >> >> 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 anyone have any suggestions/techniques? > > Hrm, your manifest should be able to handle this one on its own. > > Assuming your foo.conf file is part of the foo::config class, add this > subclass: > foo::config::arch64bit { > File["/etc/foo.conf"] { source => "..." } > } > > Then, at the place in the manifest where you pick the 64bit version of > the foo application, add an "include foo::config::arch64bit". > > Will this work for your manifest? > > Cheers, > Felix >- -- Trevor Vaughan Vice President, Onyx Point, Inc. email: tvaughan@onyxpoint.com phone: 410-541-ONYX (6699) pgp: 0x6C701E94 - -- This account not approved for unencrypted sensitive information -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNCY1LAAoJECNCGV1OLcypICYIAKwF9TvZNVt8LGY+F4Cw6gzD dbQrpVORDoJfSxCY7Yxwc9YH8NqBWaQY+A9pMvl13lReHnv3UfJGcjY9ryza6BkP sFUTuSuhOsKxoMxa5vYh5eny8QXaWSiVren46y7bis1J7qEYtgXJWXntNltNWf1M e+jZ8A2gUDV63NoO8x4SAAMPPmxugmwQW0H5JjvbERHmtV0j8DPb+xzAMCrsq2JA /eF+Gl9dtnSKQ1TWwpnyvmarIu9x0SvRX9vA1wzpzAXuqT/ZJxGUNqGg6LYPh5bm XKtHskZGedf4Qk9CaI+8WOAZSu7iUxMyBOey4ycp0+6Mf0tMJTxL2nRHFnQT89I=K3Pw -----END PGP SIGNATURE----- -- 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. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nigel Kersten
2010-Dec-16 04:38 UTC
Re: [Puppet Users] Prompting fact refresh from Puppet Event
On Wed, Dec 15, 2010 at 7:53 PM, Trevor Vaughan <tvaughan@onyxpoint.com>wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > No, because I''m not picking the 64 bit version. > > Someone else is picking the version and I have to figure out what it is > and "do the right thing", making for extra fun times. >Are their version choices sane? You can''t look at the arch of the machine and work out which version got installed?> > Thanks though, > > Trevor > > On 12/15/2010 10:12 AM, Felix Frank wrote: > > On 12/15/2010 03:46 PM, Trevor Vaughan wrote: > >> Is is possible to spawn a puppet fact refresh from the completion of an > event? > >> > >> Here''s the scenario: > >> > >> 64-bit system, either a 64 or 32 bit application ''foo'' could be > installed. > >> > >> If the 64 bit version is installed, foo.conf needs to be configured > >> with a prepended lib64 path. If not, then the 32bit default is fine. > >> > >> 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. > >> > >> 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 anyone have any suggestions/techniques? > > > > Hrm, your manifest should be able to handle this one on its own. > > > > Assuming your foo.conf file is part of the foo::config class, add this > > subclass: > > foo::config::arch64bit { > > File["/etc/foo.conf"] { source => "..." } > > } > > > > Then, at the place in the manifest where you pick the 64bit version of > > the foo application, add an "include foo::config::arch64bit". > > > > Will this work for your manifest? > > > > Cheers, > > Felix > > > > - -- > Trevor Vaughan > Vice President, Onyx Point, Inc. > email: tvaughan@onyxpoint.com > phone: 410-541-ONYX (6699) > pgp: 0x6C701E94 > > - -- This account not approved for unencrypted sensitive information -- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBAgAGBQJNCY1LAAoJECNCGV1OLcypICYIAKwF9TvZNVt8LGY+F4Cw6gzD > dbQrpVORDoJfSxCY7Yxwc9YH8NqBWaQY+A9pMvl13lReHnv3UfJGcjY9ryza6BkP > sFUTuSuhOsKxoMxa5vYh5eny8QXaWSiVren46y7bis1J7qEYtgXJWXntNltNWf1M > e+jZ8A2gUDV63NoO8x4SAAMPPmxugmwQW0H5JjvbERHmtV0j8DPb+xzAMCrsq2JA > /eF+Gl9dtnSKQ1TWwpnyvmarIu9x0SvRX9vA1wzpzAXuqT/ZJxGUNqGg6LYPh5bm > XKtHskZGedf4Qk9CaI+8WOAZSu7iUxMyBOey4ycp0+6Mf0tMJTxL2nRHFnQT89I> =K3Pw > -----END PGP SIGNATURE----- > > -- > 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%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- 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. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.... -- 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. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.