On Sep 26, 2013, at 2:44 PM, Ryan Coleman <[email protected]> wrote:


On Thu, Sep 26, 2013 at 6:45 AM, Andy Parker <[email protected]> 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?

-- 
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.

Reply via email to