Hi Kylo,
I've never used this approach since I took the assumption that my facts may
be used outside of/before all of my Puppet manifests were fully installed.
It did, at times, dictate either code duplication or the creation of an
external Ruby Gem that both could use that would be installed via the
package manager as a system dependency.
Thanks,
Trevor
On Thu, Sep 17, 2015 at 6:29 PM, Kylo Ginsberg <k...@puppetlabs.com> wrote:
> 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
> <https://groups.google.com/d/msgid/puppet-dev/CALsUZFFG%3DA0Tw3GoSnMQJ-P_2h8TNXj-BBsmUXyt9ntkZgpJ7w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
-- This account not approved for unencrypted proprietary information --
--
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/CANs%2BFoUNksZ0V2Y%3Dhn4ZkKFTPyaofqjZx1j1vVTKA8k0OsHUjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
