Hi, a while ago I've created http://github.com/ohadlevy/puppet-lookup, which is based on extlookup, but support loading data from modules.
I use it in the context of modules which i don't want internal puppet users to modify, so they can change in their location based module (so the lookup is generally inside a module - and across modules). Foreman also supports external variables lookup (with dynamic order) since version 0.1-4. my 2cents. Ohad On Fri, May 28, 2010 at 6:00 PM, Luke Kanies <[email protected]> wrote: > 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]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- 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.
