On Thu, Sep 26, 2013 at 7:23 AM, Kylo Ginsberg <[email protected]> wrote:
> On Thu, Sep 26, 2013 at 6:45 AM, Andy Parker <[email protected]> wrote: > >> On Wed, Sep 25, 2013 at 7:59 PM, John Julien <[email protected]>wrote: >> >>> This is an interesting proposal. A bit complicated, but as a result >>>> very flexible. If you recall, my main selling point for this enhancement >>>> was to include those who are not as likely to write a fact in Ruby because >>>> it is too complex for them. With that in mind, what are your feelings on a >>>> simplified version of this where we only allow the confine evaluation to be >>>> a collection of fact(s) equalling a specific value. So that might look >>>> like. >>>> >>> myfact.sh >>> myfact.sh.confine: >>> {'osfamily': 'RedHat', 'lsbmajdistrelease': 6} >>> >>> >> Agreed, the last thing that is needed is to present a solution that we >> say is to make things "easier" and then have people start the simple case >> by having to learn an abstract language expressed in data structures :) >> >> How about a hybrid approach: >> >> myfacts.sh >> myfacts.meta >> >> where meta can still contain the description, confine, etc. However >> instead of immediately forcing the author to write s-expressions they can >> do a simplified version as you propose. That way, we can start with the >> simple equality matching (that is what a hash as the value of the confine >> means), and grow to the full expressions (which would be arrays at the >> value of the confine) if the need arises. >> >> > > Are there any ordering entanglements? Specifically on > http://docs.puppetlabs.com/guides/custom_facts.html, there's the > statement "An external fact cannot internally reference another fact. > However, due to parse order, you can reference an external fact from a Ruby > fact." The directory-per-kernel approach does rely on the kernel fact but > that could be determined early, whereas this approach allows a dependency > on arbitrary facts (I think). > > Correct. You have hit upon the exact problem that my facter rewrite came up against. Once external facts can confine themselves, they become dependent on other facts. That means that in order to run any external fact, facter will need to work out what other facts it should run. Those other facts may be provided by a different external fact, which can be combined. This only becomes a problem if a cycle appears in these dependency chains; however, that is an easy enough situation to detect. I solved this in my rewrite by making a distinction between fact-indices and fact-books. The fact-indices played the role of figuring out which order things would need to be executed in by declaring what input values were needed. > Related, do we have uses cases in mind for more sophisticated confines? I > got the original concern about linux vs windows facts causing unwanted > error messages, but beyond that I don't have a feel for the likelihood > that, say, hybrid linux environments would get tripped up by > distro-specific external facts returning garbage on the wrong distro, etc. > > Right. I was trying to suss out the possible failure modes of the system. Custom facts can deal with this because they have confines and can limit the scope of where they will be executed, whereas the external facts don't. Based on the usage that John envisions, I inferred that being able to control where and when certain programs are run might be needed as the use of external facts increases. I suspect that in many cases the fact could be written in a manner that allows it to "just work" everywhere, but that also assumes a certain level of technical savvy from the author that might be better suited to some metadata and handing of the mechanics of the decision to the facter system. In the end, the conversation is good, but the minimal system that will get 80% of the use cases would likely be to start with just being able to sync external facts from modules into a known directory. The rest of these ideas can just stay as options on the table that we can decide to act on if the need arises. > Kylo > > > > -- > 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 post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-dev. > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
