Hi all,
External data (that is, data specified outside of Puppet manifests)
seems to keep coming up. This is a relatively long description of
where it seems we are and where we should go from here.
* Internally at Puppet Labs we've been discussing shipping Volcane's
extlookup as part of core.
* 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.
* External node tools are a source of external data, but they're not
yet terribly good at configuring classes, and there's no reasonable
way for a module to ship external data if you expect all of it from
the node classifier.
It seems to me we've got at least a couple of different needs we can
cleanly characterize:
* Manifests need to be able to look values up from an external data
source, preferably one value at a time
* External data will be used, at the least, for both configuring
classes (e.g., IP addresses and host names) and providing platform
flexibility (e.g., debian vs. Red Hat 5 vs. Red Hat 6)
* We need to be able to ship data with modules so that a given module
can, say, have default data for debian, red hat, and solaris.
* Users need to be able to override data with local values
Things I think are probably required:
* Users should be able to change data search paths
* Users should probably be able to put their external data in a
database, preferably in their external node tool
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.
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.
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.
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.,
search $os-$osver.yaml, $os.yaml, and default.yaml) rather than having
all of the values in a single file.
Comments?
--
The trouble with the rat race is that even if you win, you're still a
rat. -- Lily Tomlin
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
