Get Facter Facts for Previously installed module

[Ralph Bolton]

Hi,

I have a module called system_info which sets a custom fact based on some company-specific details about the host. For example, it might set something like this:

system_info_rack_number=27

(This fact is set by a lib/facter/system_info.rb bit of Ruby code, although the same is true if I set static facts)

I'd like to use this fact in other Puppet modules. There's no problem doing this in most cases, except when you're doing a bare-metal install.On a bare metal install, it runs the lib/facter/system_info.rb file as the Puppet run starts, but that returns nothing because the rest of the module isn't installed yet (so a binary it needs isn't there). That means I've got no facts on this puppet run.

This seems weird because my 'client' module can even have a "require 'system_info'" specification, which means that Puppet will (as per doco) run the system_info class in its entirety before my 'client' module - yet I don't get the facts from that module.

Is there a way around this? At the moment, I have to run Puppet twice to get things to install - which is a long way from ideal.

Any help much appreciated.

...Ralph

[Cristian Falcas]

Hi,

You could try to implement a provider for this. This will also let you
run custom code on the machine and you can run it after you have your
modules do their work.

Falcas Cristian

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/3985ef3f-3845-425a-8e8c-bee78bad5c57%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Ralph Bolton]

Custom Providers look interesting, although I can't immediately find a good example to work from (it just me, or is the puppetlabs doco weirdly confusing?). I guess it just matters when the provider is evaluated - if it's evaluated on first use, then I can make this work.

Thanks for the suggestion - I don't suppose you've got an example handy, do you?

[Trevor Vaughan]

See if this helps: https://www.onyxpoint.com/type-and-provider-execution-walkthrough/

There is a full demo type and provider linked at the bottom of the page.

Trevor

On Mon, Feb 3, 2014 at 10:34 AM, Ralph Bolton <ra...@coofercat.com> wrote:

Custom Providers look interesting, although I can't immediately find a good example to work from (it just me, or is the puppetlabs doco weirdly confusing?). I guess it just matters when the provider is evaluated - if it's evaluated on first use, then I can make this work.

Thanks for the suggestion - I don't suppose you've got an example handy, do you?

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c7d485ef-e27c-462b-bb5f-eff7428f9eb0%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Cristian Falcas]

Hi,

I learn how to do providers from this puppet book, for which you have
to pay unfortunately:

http://www.amazon.com/Puppet-Types-Providers-Dan-Bode/dp/1449339328

Cristian Falcas

> https://groups.google.com/d/msgid/puppet-users/CANs%2BFoUtbLSs9B4SzVreV9kyAb%3Dukz7CJ-06PTYCNGFVb%3DS3zQ%40mail.gmail.com.

[jcbollinger]

On Monday, February 3, 2014 9:34:51 AM UTC-6, Ralph Bolton wrote:

Custom Providers look interesting, although I can't immediately find a good example to work from (it just me, or is the puppetlabs doco weirdly confusing?). I guess it just matters when the provider is evaluated - if it's evaluated on first use, then I can make this work.

Thanks for the suggestion - I don't suppose you've got an example handy, do you?

Custom providers are interesting and useful, but they are inseparably coupled with custom types.  They have nothing to do with custom facts.  Since you are trying to inform the catalog compiler generally about details of the target node, it's definitely a fact you want, not a custom type and associated provider(s).

To your original question, the behavior you describe is absolutely normal.  A Puppet run proceeds in these general steps:

1) The agent synchronizes its local plugins with the master, including custom facts provided as plugins
2) The agent computes facts, and includes them in a request to the master for a catalog
3) The master compiles a catalog for the agent based on its manifests and the provided facts, and returns it
4) The agent applies the catalog (which may involve additional requests to the master for 'source'd files)

Note in particular that synchronizing custom fact plugins is not part of applying the catalog; the relative timing of this operation is completely unaffected by anything in any of your manifests.

As you can see, it's a bit infelicitous to use a custom fact that depends on a separate custom binary.  Installation and update of such a binary via Puppet will always trail computation of the fact value, and you have to somehow account for that.  If you can put the whole value computation directly into your fact plugin then you will be better off.

If you cannot avoid your fact relying on an external custom binary, then you might consider overcoming the need to install that binary via Puppet.  For example, you might put it on a network filesystem from which clients could run it without any local installation.  If the binary is not expected to change during the lifetime of a system (and maybe even otherwise) then you could install it as part of the initial provisioning process.

If you want to manage the binary via Puppet, then you need to accept that two catalog runs will be required to sync systems when they are first installed and when the binary needs to be updated.  There are various ways to dress that up to better suit your specific objectives, but that's the bottom line.


John

[Ralph Bolton]

Thank you all for your responses.

From John's response, I see that I'm going to struggle here. Ultimately, I am just trying to get some details about the system, and will look into installing our system info script as part of the OS build. Truthfully though, it's not doing so much that I couldn't just write it in Ruby and have it run during the fact gathering stage of the initial puppet run. I would have liked to avoid this though, as it means the same functionality will live in two places. I guess one day the binary could just be reporting facts rather than being the source of truth itself. It's not so terrible to do this, but it's a shame I can't just integrate Puppet with my world, but instead have to make the world integrate with puppet.

This could all be solved if there was a way to make Puppet re-evaluate facts either on request during a module's execution, or to have them evaluated on first use (after all, they are written as "fact name = X, code to execute to get its value = Y"), or some other means. Does any of this sound like desirable behaviour or worth taking it up with Puppetlabs for the future?

...Ralph

[jcbollinger]

On Wednesday, February 5, 2014 3:09:48 AM UTC-6, Ralph Bolton wrote:

Thank you all for your responses.

From John's response, I see that I'm going to struggle here. Ultimately, I am just trying to get some details about the system, and will look into installing our system info script as part of the OS build. Truthfully though, it's not doing so much that I couldn't just write it in Ruby and have it run during the fact gathering stage of the initial puppet run. I would have liked to avoid this though, as it means the same functionality will live in two places. I guess one day the binary could just be reporting facts rather than being the source of truth itself. It's not so terrible to do this, but it's a shame I can't just integrate Puppet with my world, but instead have to make the world integrate with puppet.

That strikes me as a little overblown.  Integrating two systems almost always involves some kind of adaptation.  At minimum you need to modify "the world" to include installing Puppet.  And if you're relying on your custom binary now, then your world already includes some means for getting it onto systems -- continuing to use that would be less change, and if you didn't want to do that then you were planning on changes in that area anyway.

 

This could all be solved if there was a way to make Puppet re-evaluate facts either on request during a module's execution, or to have them evaluated on first use (after all, they are written as "fact name = X, code to execute to get its value = Y"), or some other means. Does any of this sound like desirable behaviour or worth taking it up with Puppetlabs for the future?

Re-evaluating facts during a catalog run: absolutely not.  The stability and self consistency of Puppet catalogs depends on all variables, including facts, to keep the same value.

On the other hand, deferred fact evaluation is an interesting idea, but more problematic both to build and to use than you probably suppose.

You are not the first to struggle in this area.  The original idea for "run stages" involved the agent running several times in succession, once for each applicable stage.  That sort of behavior would fit your problem nicely, but alas, the ultimate implementation of run stages went in a completely different direction.  Still, it should be possible to build a mechanism for Puppet to trigger a fresh run after the current one is done.


John

[Ralph Bolton]

Sounds fair enough.

So I've had a look at what we've got, and it's not an onerous amount of code that needs translating and implementing as facts. The problem really is the development environment which is very straight forward with our binary as it can be entirely built, tested and installed in isolation. Doing the same in puppet facts libraries isn't impossible, but it's harder, and a bit more 'specialised'. I'll get it done though, given time...

I'll leave Puppetlabs alone then - you make some good points, and as you've highlighted, once this is turned around there's really no need for any change to Puppet itself.

Thanks for your help :-)

...Ralph