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 <[email protected] > <javascript:>> wrote: > >> On Thu, Sep 17, 2015 at 11:27 AM, <[email protected] <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 [email protected] <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 | [email protected] <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 [email protected] <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 [email protected]. 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.
