On May 13, 8:07 am, jcbollinger <john.bollin...@stjude.org> wrote: My apologies for the empty post.
I agree that it is silly to suppose that extlookup() is a universal solution, but personally, I don't take that impression from web comments in the first place. In fact, Puppet Labs's own recently updated style guide recommends against using extlookup(), though that position is controversial. I also agree that for some sites, a richer / more powerful lookup feature might be needed. On the other hand, extlookup() is easy to set up and use, and it is powerful enough for most needs. If you need a more powerful data lookup function then you would be lucky to find a canned one that meets all your needs. Moreover, I disagree with several of the opinions and conclusions in your post: 1) You write: "The extlookup() functionality only allows [... specifying implicitly ...] where to look for this value." That is false. Extlookup does provide for configuration of a standard set of CSV files to search (which can be parameterized by nodes' facts), but the function also has an optional parameter to specify a specific file to be searched first on any given invocation. 2) You would prefer looking up data via a compound key (config_item, lookup_value) rather than via a simple key (config_item). You rightly observe that this would sometimes allow fewer files to be used than are needed in the current implementation, because different values for the same item could be distinguished by the "lookup_value" instead of by the file in which they reside. The trade-off, however, is that every lookup is more expensive, because on average the function would need to read more lines, and to perform a more complex analysis on each one. In your blog you suggest a DB backend, but that's not really relevant because by that point you have a completely different function than extlookup(). And even a DB performs multi-key queries slower than single-key searches. 3) You argue that your suggested formulation of extlookup would be "clearer as the configuration is more explicit then the current extlookup() definition." I think you're missing the point. It would indeed be clearer from which file the data would come, but the objective of extlookup is to separate the *definition* of the data as much as possible from the *use* of the data. And I like that. I prefer that my manifests _not_ specify a bunch of details to every extlookup() call, because that would obscure the details that are important at the manifest level. 4) You seem to want to use an arbitrary-length list of values as your lookup key, but I don't see how that can work while retaining the apparent objective of reducing the number of data files that must be associated with your configuration and retaining the use of CSV. 5) You write "Using the current (puppet 2.6) mechanism would require me, if I understand it correctly, to configure different .csv files to be searched for each 'configuration parameter'." Perhaps, but I think that's a bit of a straw man in that you are supposing a usage mode for extlookup that isn't well attuned to its design. Although it can support them, extlookup is not designed for data domains that are parameterized along many different dimensions. More to the point, such extensive parameterization is rarely needed in practice. 6) You write "I may also need in several places to override the $extlookup_precedence. In any case this can’t be overridden several times within the same module which is what I would need if I want to lookup different variables." I don't follow. In the first place, you can always use extlookup's third parameter to specify a particular file to check first. In the second place, your data are not well- defined if it seems to make sense to alter the lookup precedence of files that are already in the search path. Let me not be taken as an extlookup() zealot. I do like the design as it is, but that doesn't mean it is ideal -- or even good -- for every purpose. One of the advantages of Puppet, however, is that it is fairly easy to modify and extend. If you would like an alternative lookup facility then by all means, write one. If you are community- minded then you could consider sharing it; the Puppet Forge (http:// forge.puppetlabs.com/) makes it easy to do that. You may also be interested in some of the extlookup() author's comments about it (http://www.devco.net/archives/2009/08/31/ complex_data_and_puppet.php). He hangs out here, so you may also hear from him directly. Best, John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
