hello,
----- "Luke Kanies" <l...@puppetlabs.com> wrote:
> * Alessandro's presentation caused someone to point out to me
> afterward that case statements of this ilk:
>
> case $operatingsytem {
> debian: { ... }
> redhat: { ... }
> }
>
> make a module difficult to extend with support for new operating
> system types - you have to modify the module itself in this case.
extlookup exist specifically to avoid this and the resulting:
find . -name \*.pp | xargs grep -l operatingsystem
> So, the questions become, what should we do here, and are any of the
> solutions we have right now good enough to ship today?
> extlookup currently uses CSV for external data, and I don't think most
> users will want to use that. At the least, any long-term answer needs
> to support something more user-friendly like YAML. It also doesn't
> support multiple data sources (e.g., YAML and external node) nor does
> it (AFAIK) support data in the module plus a central data directory.
CSV is a path of least resistance approach to me, i dont need to teach any
new person on irc anything at all to use them. I agree for real work they
are not the way to go and should be replaced.
>
> From what I can tell, it's well suited to filling out things like IP
> addresses, host names, etc., but not as useful for providing module
> portability by filling in different values for different operating
> systems or something.
you can very easily use it for this, see below.
> I also don't like the idea of just relying on a function - I'd like a
> class to be able to declare that it relies on external data, so that
> users know what they can configure in their class.
ditto, all for this, this is my main concern with merging it the result while
pleasing is the best I could come up with as a function but not I think the
best solution. If PL is going to throw resources at this specific problem
space I would like to see it improved past what I can do in a function.
> Fortunately, extlookup is a very short function, so it should be
> straightforward to extend it if we decide to do that.
>
> I'm thinking that we should ship something simple for rowlf, but I
> think it should avoid CSV (probably using yaml instead) and it should,
> at the least, support a global data directly and per-module data
> directories. It should also allow multiple files for searching (e.g.,
this is easy to do - per module stuff, Ohad has a fork/similar tool that
achieves that
> search $os-$osver.yaml, $os.yaml, and default.yaml) rather than having
> all of the values in a single file.
that's exactly what it does now.
a user configure that in their case they search:
fqdn, data center, country, client, operatingsytem, common
another user configures it to search on:
fqdn, operatingsytem, common
the code does:
extlookup("http_pkg_name")
and gets back an answer that gets resolved in however the user configured his
data.
Thats the main beauty of it for me, I can write on set of code and when I share
that module
with another user how the module resolves data depends on that users local
setup and not
code in the module.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
