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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fbce8335-d584-4bd3-8a18-14c2a96e3a87%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
