Agreed. We could have done:
%{scope('some.dotted.key')}
and then
%{hiera('some')[dotted][key]}
or limited the use of dotted keys to scope interpolation. Such a
solution would have satisfied the requirements expressed in the
description of HI-14 (albeit, as you mention, the title has a more
general wording). If our objective was to deliver a Hiera 1.3.5 or even
a Hiera 1.4.0, that's probably what we would have done.
With Hiera 2.0.0 we decided to go for a simple syntax that was
applicable everywhere. It simple, consistent and will avoid future
questions like; why is it only possible to traverse scope data and not
other structured data? Why is a key interpreted different in this
interpolation expression than in that? Why can't I use a dotted key in
the lookup when I can use it in interpolation? Etc.
The change will only affect sites where dotted keys are used in Hiera
data negatively and it's not the only breaking change in Hiera 2.0.0.
A side note:
Hiera.lookup('some')['dotted']['key'] will not always return the same
object since the 'some' may return a Hash where 'dotted' is missing from
the first backend but not in the next. The interpolation expression
%{hiera('some')[dotted][key]} would, if implemented consistently, share
that behavior. For the lookup, a possible remedy would be to use a
'hash' + deep merge but that's not possible when using interpolation
expression. I'm well aware that it's a corner case but it does show the
advantage of using a simple and consistent interpretation of the lookup key.
- thomas
On 2015-04-02 21:19, John Bollinger wrote:
On Thursday, April 2, 2015 at 10:33:02 AM UTC-5, Thomas Hallgren wrote:
John,
The HI-14's requested behavior was not implemented as an
afterthought. On the contrary. Since all facts have been available
in the top scope since Puppet 3.5, there was simply no need for a
specific handling of facts in Hiera and the approach taken was
very deliberate. We knew that whatever we would put in place would
be applicable for all variables in the scope. We also knew that
since scope variables are not the only structured data out there,
it would be somewhat congested to create solution that would work
/only/ with scope variables but not with everything else. I think
that would have been a really bad decision and as far as I can
remember it was never brought up to discussion.
Am I misspelling of the word "interpolation", or something? Is it too
similar to the word "interpretation" that I have been using to talk
about how hiera translates keys into corresponding values? I'm
getting frustrated here.
I have not suggested that the new feature should have been restricted
to facts specifically or even to variables generally. Although HI-14
uses facts as its examples, the text is not so restrictive, and I
agree that such a solution would have been awkward. No, I am saying
that the change should have been restricted to the context of
interpolation tokens, on account of that being the only context
contemplated by the feature request. Protestations notwithstanding,
that aspect of the change has clearly gotten little love, even though
it is both the actual intended target and by far the most important
part. It provides for doing things with Hiera that were difficult or
impossible to do before.
The change to key interpretation, on the other hand, is largely a
solution without a problem, and, moreover, without any request or
change approval that I have seen. I probably wouldn't be so on about
it if it did not constitute a breaking change, but I find it pretty
concerning that a breaking change is introduced without request,
approval, or any particular justification other than possibly that it
was more convenient to make the change than to avoid making it.
Mustering up some charity, I am prepared to believe that the changes
were implemented based mostly on the ticket title, without an
effective analysis of the actual problem as set forth in the
description text. That's only a possible explanation, though, not a
justification.
The current solution works with:
%{scope('some.dotted.key')}
Yes.
and
%{hiera('some.dotted.key')}
Why?
and
Hiera.lookup('some.dotted.key')
Why?
The interpolated hiera lookup is implicitly doing the last one so
they need to come as a package.
Fine, the last two need to come as a package, but why did either one
need to come at all? What would have been the problem with, say,
%{hiera('some').dotted.key}
or
%{hiera('some')[dotted][key]}
or any of probably a dozen other alternatives? Surely wherever
Hiera.lookup('some.dotted.key') now returns an object,
Hiera.lookup('some')['dotted']['key'] always did return that same object.
My apologies. Please feel no obligation to respond to those
implementation-directed comments. With the interpolation angle
actually covered (its total lack of documentation notwithstanding), my
concern is now much more with how and why the change ended up
exceeding its requested scope than with the details of change itself.
The merits of the change to key semantics aside, that change should
not have been implemented under the auspices of HI-14 as it is written.
In the end, of course, PL's change management processes are none of my
responsibility. I am speaking from the perspective of a concerned
bystander with a vested interest in Puppet and PuppetLabs remaining
strong and effective, and playing fast and loose with the change
management process is not supportive of continuing effectiveness.
Frankly, at this point I am even more more concerned that no one seems
to want to acknowledge that there even was a problem with how this
went down than I am with the fact that it did go down. But if I am
whistling in the wind, then so be it.
John
--
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+unsubscr...@googlegroups.com
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/c522c4a4-832b-4915-909d-877af185ef5f%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-dev/c522c4a4-832b-4915-909d-877af185ef5f%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/551DB9B7.8040400%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.
