On 2013-26-06 18:35, Andy Parker wrote:
On Tue, Jun 25, 2013 at 8:15 PM, Henrik Lindberg
<[email protected] <mailto:[email protected]>>
wrote:
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).
Yes, that looks like the ability in Puppet Templates. There, the
template starts with a declaration of its parameters.
An idea is that the hiera strings are EPP :) either make hiera evaluate
them (magic), or lookup and evaluate.
inline_epptemplate(lookup(mykey), { x => $my_x })
The hiera string would then contain EPP e.g.
"<%- ($x = 'no x given') -%>
I was given an x with value <%= $x %>, that
when looked up became <%= lookup($x) %>
Bye"
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.
I would like to not support them as they need to be evaluated
dynamically, but that is a different story. Absolute is fine since a
particular dynamic scope is then not needed and it is then not possible
to reference variables inside a define, or in a local scope in a lambda.
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}')}
hm, no escaping? I would expect \% to escape a % etc. like everywhere else.
- 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.
