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
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) 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 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?
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)}'
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 [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.
