> > So one thought, what if there were one (and only one) place to get the > > environment but the value could optionally be an > > expression/lambda/special token of some sort that would pull the value > > from some other (specified) location? > > > > That gets rid of the whole issue of what-trumps-what, or at least > > sidelines it; we may still want some sources (e.g. the command line) > > to take precedence but we don't have to sort a long list of sources > > based on a whole slew of use cases. > > > > * Does that sound reasonable? > > * Where should the one-true-place be? > > * Is the command line (for interactive use) the only thing that should > > best it? > > * Are there any use cases that this wouldn't handle? > > sounds plausible but abstract, can you show some kind of potential use case > or something so we can have an idea of what you're thinking? >
*laugh* It was intentionally abstract, because I wanted to know what _you_ were thinking. But since you asked, here are two concrete strawman examples: 1. The environment comes from the client's conf file, unless overridden by the command line. Normally, this is a literal string value, but it could be one of several special values such as "!!FACT[fact name]" or "!!NODE_TOOL" or some such. If one of these is used the appropriate action is taken to resolve the host name. 2. The environment is always determined by facter. Facter has the ability to get the information from various places, such as the client config, the node manager (by templating the fact or some other such ruse), and so forth. Pretty much any of the sources could be used in this way, though the dynamics of how things would play out--and the complexity of implementing it--would vary considerably. I'm not proposing any of them specifically, just exploring ways we could trim the growing list of places the environment could come from (there are presently six on the table by my count). -- Markus --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
