On Thursday, September 26, 2013 2:18:06 PM UTC-5, Luke Kanies wrote: > > On Sep 26, 2013, at 2:44 PM, Ryan Coleman <[email protected]<javascript:>> > wrote: > > > On Thu, Sep 26, 2013 at 6:45 AM, Andy Parker > <[email protected]<javascript:> > > wrote: > >> 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. >> > > I'm a little concerned about the complexity being proposed here, even in > this slightly more reserved hybrid approach. Extending pluginsync to > shuffle external fact scripts around seems reasonable enough but I'm > unconvinced that it's right to add what equates to metadata for each fact > in order to achieve it. External facts are meant to be a simple interface, > right? > > How often would you reasonably need to confine an external fact script > like that? At this point, what's wrong with the tiny overhead of a real > ruby Fact? > > > I'm also concerned about the complexity. > > Is it reasonable to provide less of a framework for external facts? That > is, if you're writing an external fact, it needs to either work on any host > on which it resides, or be an executable that returns nil on an invalid > host. > > I could also see defining an output format, which we almost have to have > anyway (to support structured facts), and supporting metadata in that > format, but it seems like if you're just using yaml or json, then you > should accept a very limited interface. If you want more power, move up to > a more powerful language. > > Would that be an acceptable balance between power and simplicity? > My goal is to allow admins to write facts in shell, since that's what they know. The difficulty of requiring people to write a fact that executes on any platform is availability of the interpreter. I'm thinking specifically /bin/sh not existing on windows or a .bat script executing properly linux.
I looked a bit more in depth at the facter code (and ran puppet on windows for the first time to confirm) and turns out, this won't actually do anything funky on windows unless someone ends their bash script with a .com or .exe. As of Facter 1.7.3 this extension is explicitly required for executable windows facts. The breakage actually occurs on Linux when a windows fact gets synced down with .exe. Because the Linux check is just, is it executable. So we could say, is it executable, and make sure it does not contain a windows extension for Linux. That would end that debate. There still is the issue of a unix style fact being put on AIX, Linux, and HPUX where it requires say "lsvg" which is an AIX only command. In this case, we could employ the policy that it is up to the programmer to make sure their fact is valid for the OS it is being run on. If someone has say AIX and Linux sytems, then they may need to do their own check to figure this out and exit early if necessary. When I used to support multiple platforms it was not uncommon to see a case statement against `uname` at the top of a script. So to summarize, I like the idea of just make the programmer responsible. If their environment is complex, they may need to place a bit of "suitability" logic at the top of their script. I think facter has to make this determination for Windows Vs. Linux by not executing facts on Linux with common windows extensions. -- 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.
