I saw a fact recently that utilized the package type to lookup if a package
was installed. It seemed like a cool hack considering the amount of code
it takes to see if a package is installed on windows. So I thought I might
see if I could do the same thing with my bmc type. My other approach is to
use my gem rubyipmi which is command agnostic. However, I am shying away
from the gem route because its yet another dependency for the user to
install. Not that its hard to install a gem from puppet or by hand but
some folks don't have internet or need to approve all software before
using.
Anyways, I think I got what I wanted out this conversation, although your
welcome to add your input.
Corey
On Friday, September 18, 2015 at 6:54:24 AM UTC-7, Trevor Vaughan wrote:
>
> 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 <ky...@puppetlabs.com
> <javascript:>> wrote:
>
>> On Thu, Sep 17, 2015 at 11:27 AM, <jeremia...@seagate.com <javascript:>>
>> 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+...@googlegroups.com <javascript:>.
>>> 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 | ky...@puppetlabs.com <javascript:> | 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+...@googlegroups.com <javascript:>.
>> 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/fc2f4cfc-8d3f-490a-a410-416989009d6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
