On Wednesday, September 16, 2015 at 10:11:16 PM UTC-5, Corey Osman wrote:
>
> Is it considered bad practice to make use of a custom provider code to
> retrieve values for a fact?
>
> example:
>
> Facter.add("bmc_ip", :timeout => 2) do
> confine :bmc_device_present => [:true, true]
> confine :bmc_tools_present => [:true, true]
> setcode do
>
> Puppet::Type.type(:bmc).instances.first.retrieve_resource.to_data_hash["parameters"][:ip]
>
>
> end
> end
>
> Since the fact and provider code overlap each other with what it gathers I
> was looking for a tool-agnostic way
> to retrieve some values from the BMC device. What I like about this is
> that the fact uses puppet to figure out
> how to retrieve the data without making the user choose a specific tool
> for fact values.
>
>
>
> Corey
>
Considering the order of the Puppet agent run I would expect, having a
provider start up during fact collection to create a fact would be
surprising behavior to me.
I usually architect types and facts the other way around. So I am
interested in the community opinion on this.
If I'm writing a native provider that has some useful fact-like data then I
write a fact and use that in the creation of the provider. This ensures
I'm not duplicating logic all over the code base.
Some providers need a key fact to do much of their work. Facter can cache
that at the start of the run instead of recalculating it or duplicating the
logic in many providers. Plus the fact can be confined to systems where
the providers may not run.
However, my facts tend to be encapsulated in a sub-module of Facter::Util
and not simple execs. This enables organized construction of complex
facts while the actual Facter.add block remains trivial. The module-based
fact can be unit tested with puppet-rspec function matchers.
Care has to be taken at that level of programming. If the Facter fact
module is imported to use the module directly instead of using the
Facter.value call the fact will run multiple times. But the ordering of
plugin-sync and fact collection before resource evaluation ensures the fact
has already run or failed before the native type needs it.
If the goal is a tool agnostic approach then this is just forcing some
provider in Puppet to pick a tool for you. If the fact didn't work you
could write your own provider to pick a tool if needed. So there is that
advantage to a provider-based fact in place of a fact-based provider.
Jeremiah
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/71cc46cb-251e-402d-b748-f0be8dc530db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
