On Thu, Sep 17, 2015 at 11:27 AM, <jeremiah.pow...@seagate.com> wrote:
> 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.
>
Agreed, and I can think of a least one case where someone hit a gotcha with
this kind of surprising behavior before. The scenario there was that we
wanted to specify a type default to suppress an unwanted warning message,
but since the provider code was loaded during fact collection, before any
manifests were involved, the change appeared never to take effect. The
circular dependency (of puppet requiring facter which required puppet to
collect the facts) made for an, ahem, entertaining debug process.
> I usually architect types and facts the other way around. So I am
> interested in the community opinion on this.
>
Likewise. I'm curious to know if this pattern is very common, and if so,
what some alternate patterns are, what the tradeoffs are, etc.
Kylo
>
> 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
> <https://groups.google.com/d/msgid/puppet-dev/71cc46cb-251e-402d-b748-f0be8dc530db%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Kylo Ginsberg | k...@puppetlabs.com | irc: kylo | twitter: @kylog
--
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/CALsUZFFG%3DA0Tw3GoSnMQJ-P_2h8TNXj-BBsmUXyt9ntkZgpJ7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
