On Tue, Jun 25, 2013 at 8:15 PM, Henrik Lindberg < [email protected]> wrote:
> On 2013-26-06 3:06, Eric Sorenson wrote: > >> Hi, there's been a lively discussion on an interesting pull request that >> came in: >> >> https://github.com/puppetlabs/**hiera/pull/137<https://github.com/puppetlabs/hiera/pull/137> >> >> In the interest of soliciting input from a wider audience I'd like to >> move the discussion on this request to the list. >> >> Personally I have two issues, one major/semantic and one minor/syntactic. >> >> The major problem is that this seems to reverse the entire goal of >> "separate data from code" by putting code back into data. In addition to >> the issues @ripienaar raised in [the previous recursion PR]( >> http://projects.**puppetlabs.com/issues/18030#**note-7<http://projects.puppetlabs.com/issues/18030#note-7>) >> around visibility/action-at-a-**distance, this seems to make "more >> magic" and I feel pretty strongly that we need less magic even if it comes >> at the expense of more code -- in this case, a puppet manifest variable >> that does the stringified variable interpolation you're proposing in the >> data. >> >> The minor problem is that, as Henrik notes, Hiera already has ONE syntax >> for variable interpolation that uses a different sigil to Puppet's. That's >> kind of weird, and again I'd like to see changes that bring the ecosystem >> closer together, not push it further apart. >> >> > My thinking is... > > Hiera allows interpolation of variables from scope. I would like to > restrict scope variable interpolation to only accept top-scope variables > set at the point where an ENC has done its job (i.e. facts + whatever was > set by the ENC). I see it as quite problematic that a lookup can access > whatever happens to be in context. It leads to hard to find problems, > leaking of information, and poor separation of concern. It also leads to > uncertainty after the fact where the interpolated value came from, it makes > it impossible to cache the result, and it is impossible to do upfront > validation. > > > [1,2,3].collect |$x| { lookup(mykey) } > > where mykey is defined in hiera as '# %{x}' will produce > > ['# 1', '# 2', '# 3'] > > Surprise when user changes 'x' to 'y', or if there was an 'x' in the outer > scope that the user shadowed unknowingly of the interpolation of 'x' in > mykey. > > I could see this working if you can also specify a collection of extra data. lookup('mykey', { x => $my_x_value }) This is a very common way of controlling and making explicit what data is visible to the lookup function and gives a lot more control over it (and refactorings like the one you mention remain safe). > I am ok with interpolating global/topscope variables though since they > are bound at the start of the evaluation (and do not change). > > I wonder how many that actually makes use of the feature to interpolate > scoped variables from the calling scope in their hiera-data? > > I know of one team where it being more that topscope caught them completely off guard (there was a parameter called $environment to a class and that completely changed the hiera lookups inside that class). I think more likely is that hiera data is depending on fully qualified variable names. > W.r.t interpolation of other hiera keys I have (perhaps surprisingly) > fewer issues. Since it is known at the start of evluation what is bound to > the respective keys and the designer of the data layout is responsible for > both keys there is really no problem (i.e. it is the same concern). One > naturally has to check for circularity, but that is a small implementation > detail. > > In the PR where the discussion started I made some proposals. I am > repeating them here with more motivation. > > Since hiera uses %{} for interpolation of scope, and one can see this as > being the same as the ${} interpolation in Puppet DSL, it seems natural to > allow an expression. e.g. in Puppet DSL one would interpolate a lookup by > writing: > > "the data is ${lookup(a_key)}" > > Why not simply do the same in the hiera data? i.e. > > 'the data is %{lookup(a_key)}' > Expanding hiera interpolations to allow this would actually also allow another thing that is asked for: https://projects.puppetlabs.com/issues/16235 If the %{} syntax allowed more complex expressions then I could see this being used to specify a literal value in order to achieve "escaping". So in order to get %{SERVERNAME} in the value of a hiera lookup (which isn't possible right now) you could do something like: %{literal('%{SERVERNAME}')} > > Hiera would not have to parse and handle all expressions, just the call to > the lookup function. (Later this can be expanded with use of the future > parser). > > There are also other alternatives. When Puppet Templates are added, it is > possible to bind a template string containing puppet logic, and evaluating > that. The puppet templates can be parameterized (like function) which > enables them to be free of concern w.r.t the context where they are > evaluated. > > The fact that hiera uses %{} instead of ${} is unfortunate, and probably > not something we can easily change without risking breaking peoples data > (containing ${} for other purposes). > > More longer term, ARM-8 defines how data is expressed in Puppet DSL > language and the difference %{} ${} will be resolved (together with the > issues of supporting variable lookup as well as interpolation of other > keys. (The semantics for when things are bound are much tighter). > > Finally, if you think it is a chore to write something like: > > lookup(key) > > and would like that to be baked into the language itself via syntax, I may > be persuaded ;-) even if lookup(key) is more descriptive than a syntactic > marker (we are starting to run out of them btw). > > Looking forward to hearing everyone's opinion. > > Regards > - henrik > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > puppet-dev+unsubscribe@**googlegroups.com<puppet-dev%[email protected]> > . > To post to this group, send email to [email protected]. > Visit this group at > http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2013, August 22-23 in San Francisco - * http://bit.ly/pupconf13* **Register now and take advantage of the Early Bird discount - save 25%!* -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
