Re: ARM-8 (Hiera 2) Draft

[Henrik Lindberg]

On 2013-05-06 22:47, Joshua Partlow wrote:
> Hi
>
> Henrik has a draft in place for work he's been doing specifying a new
> injection mechanism which would subsume hiera 1.. The draft is here:
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md
>
> He's called out a number of discussion point areas, which I've provided
> links to below with some initial responses in order to establish the
> arm-8 discussion thread. (although I may have munged some of them
> incorrectly)
>
Thanks Joshua, for creating the tread and the feedback.
> ---
>
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#use-hardcoded-environments
>
> site.pp appears to be configurable in puppet-conf, so I think
> environments.pp should be as well.
>
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#use-magical-return
>
> -1 on magical returns for site {} to $environment; I don't think you
> want $environment set by accident.
>
agree, -1 for me as well.

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#provide-access-to-classes-and-parameters-in-environmentspp
>
> Agreed, classes and parameters from ENC seem superfluous in this step.
>
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#conditional-categories-or-not
>
> -1 on conditionals in site { categories {} } unless we are positive the
> complexity is required and can't be dealt with in another way.
>
that is what I think too, but need input from people with
advanced/complex use cases.

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#explicit-when-common-or-not
>
> Allowing `when common {}` seems clearer, but I wouldn't require it.
>
I am fine with both, but since most are likely to write without common
{} it does not help much...

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#precedence-score---how
>
> It doesn't seem clear to me that a nested binding necessarily should
> have precedence over an unnested one. I think this is a case where we
> need to let people know about the conflict and let them resolve it in a
> higher layer.
>
Wouldn't you be more surprised if a binding for "red" and "kermit" did
not win over a binding for just "kermit" ?

> I would not try the alt scoring method yet. Though deterministic, I
> think it's too open to surprising the user rather than just letting them
> know what is in conflict.
>
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#support-when-with-or-semantics
>
> I'm the fence here; but leaning towards simplicity without 'when a or b'
> to begin with.
>
"or" is better than "," - I am going to change that.

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#is-abstract-too-abstract
>
> I'm showing my own bias--abstract seems right to me.
>
> bind stub "foo"
>
> bind empty "foo" # but this might make people think they were 'unbinding'
>
> bind placeholder "foo"
>
> stub "foo"
>
> declare "foo"
>
> name "foo"
>
> bind no body "foo"
>
> or just accept
>
> bind "foo" # but that seems too likely to hide mistakes.
>
> bind abstract "foo" # still seems best
>
You came to the same conclusion I did. I could not come up with a better
alternative.

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#is-override-too-overloaded
>
> Do you mean as a word or is it used in two different areas in the
> proposed language?
>
Same keyword used in two places, with slightly different meaning. Also
the act of "overriding" may be more conceptually closer to doing a
binding in the user's mind - i.e. any binding is a potential override.
I used override since it is @Override in Java.

> override "foo" to 42
>
> or
>
> bind overridding "foo" to 42
>
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index..md#lambda-or-type-reference-to-get-an-instance-or-support-both
>
> I'm already concerned that lambda's are mind-blowing (albeit powerful).
> But given that complex multibind merges need something to sort them out,
> having lambdas available for that seems best. Plugging in a runtime
> class seems like something that could be added later.
>
Using a class would be far simpler parse/implementation wise but puts
the onus on the user to have to write a ruby class a special way for
what is probably just a couple of lines of puppet code.

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#use-keywords-include-and-exclude-for-class-inclusion-and-erasure
>
> Having a shortcut syntax for this seems like a good idea.
>
good - I think so to.

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#are-includeexclude-as-keywords-overloaded---use-something-else
>
> I think the overloading is fine. Right now I'm thinking that adding
> layers with intricate include/exclude parameters is going to be much
> rarer thatn including and excluding clases.
>
Yes, I expect that normal use is very straight forward both for classes
and parameters. It is when people start to change things and can't
change everything at once that the more advanced features become important.

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#is-it-of-value-to-pick-parts-from-an-enc-to-hiera2-transformation
>
> Given that it's a small addition to an already complex area, it might be
> useful for migration as noted.
>
It is certainly no big deal to implement.

Regards
- henrik

[Henrik Lindberg]

On 2013-05-06 22:47, Joshua Partlow wrote:
> Hi
>
> Henrik has a draft in place for work he's been doing specifying a new
> injection mechanism which would subsume hiera 1.. The draft is here:
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md
>
> He's called out a number of discussion point areas, which I've provided
> links to below with some initial responses in order to establish the
> arm-8 discussion thread. (although I may have munged some of them
> incorrectly)
>
>

To people reading the draft at this point - it is an early draft and all
of the motivation and surrounding text is not yet in place.

I guess that is to say that there is lot of technical detail and
complexity that at first may seem unmotivated. Sorry about that - both
motivation and simpler examples will be added in coming revisions.

Regards
- henrik

[Andy Parker]

Please add the motivation and examples soon, or else all feedback will be in a vacuum.

 

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.
To post to this group, send email to puppe...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--

Andrew Parker

an...@puppetlabs.com

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%!

[Joshua Partlow]

On Wednesday, June 5, 2013 5:15:15 PM UTC-7, henrik lindberg wrote:

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#explicit-when-common-or-not
>
> Allowing `when common {}` seems clearer, but I wouldn't require it.
>
I am fine with both, but since most are likely to write without common
{} it does not help much...

Definitely, I just think that since the common case is a short cut, writing it out 'longhand' as it were should parse.

 

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#precedence-score---how
>
> It doesn't seem clear to me that a nested binding necessarily should
> have precedence over an unnested one.  I think this is a case where we
> need to let people know about the conflict and let them resolve it in a
> higher layer.
>
Wouldn't you be more surprised if a binding for "red" and "kermit" did
not win over a binding for just "kermit" ?

Yes, but I would also expect "kermit" to take precedence over,  "production { virtual }", so there are both surprising and non-surprising results, which is why I think we need to be explicit about any conflicts rather than try to apply heuristics to resolve precedence.

 

> I would not try the alt scoring method yet.  Though deterministic, I
> think it's too open to surprising the user rather than just letting them
> know what is in conflict.
>

> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#is-override-too-overloaded
>
> Do you mean as a word or is it used in two different areas in the
> proposed language?
>
Same keyword used in two places, with slightly different meaning. Also
the act of "overriding" may be more conceptually closer to doing a
binding in the user's mind - i.e. any binding is a potential override.
I used override since it is @Override in Java.

Where are the two cases?  I only see 'binding override'

 

> override "foo" to 42
>
> or
>
> bind overridding "foo" to 42

--Josh 

[Henrik Lindberg]

On 2013-07-06 8:37, Joshua Partlow wrote:
> On Wednesday, June 5, 2013 5:15:15 PM UTC-7, henrik lindberg wrote:
>
> >
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#explicit-when-common-or-not
> <https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#explicit-when-common-or-not>
>
> >

> > Allowing `when common {}` seems clearer, but I wouldn't require it..

> >
> I am fine with both, but since most are likely to write without common
> {} it does not help much...
>
>
> Definitely, I just think that since the common case is a short cut,
> writing it out 'longhand' as it were should parse.
>

I am ok with that.

> >
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#precedence-score---how

> <https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#precedence-score---how>
>
> >
> > It doesn't seem clear to me that a nested binding necessarily should
> > have precedence over an unnested one. I think this is a case
> where we
> > need to let people know about the conflict and let them resolve
> it in a
> > higher layer.
> >
> Wouldn't you be more surprised if a binding for "red" and "kermit" did
> not win over a binding for just "kermit" ?
>
>
> Yes, but I would also expect "kermit" to take precedence over,
> "production { virtual }", so there are both surprising and
> non-surprising results, which is why I think we need to be explicit
> about any conflicts rather than try to apply heuristics to resolve
> precedence.
>

well, kermit and virtual would win over just kermit, or just virtual.

> > I would not try the alt scoring method yet. Though deterministic, I
> > think it's too open to surprising the user rather than just
> letting them
> > know what is in conflict.
> >
> >
> https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#is-override-too-overloaded
> <https://github.com/puppetlabs/armatures/blob/master/arm-8.hiera_2/index.md#is-override-too-overloaded>
>
> >
> > Do you mean as a word or is it used in two different areas in the
> > proposed language?
> >
> Same keyword used in two places, with slightly different meaning. Also
> the act of "overriding" may be more conceptually closer to doing a
> binding in the user's mind - i.e. any binding is a potential override.
> I used override since it is @Override in Java.
>
>
> Where are the two cases? I only see 'binding override'
>
> > override "foo" to 42
> >
> > or
> >
> > bind overridding "foo" to 42
>
>

I was wrong - one is the keyword, and the other the concept of
"overriding" bindings - as the question states - layers and categories
have precedence, and you are thus overriding (conceptually). To then
also have a keyword that states "override" makes it confusing, the ones
that are not marked that way may be conceptual overrides. So, that is
the real question. In a way I am tempted to not include support for
declaring "override" even if it is a valuable quality feature.

A great term would help here.

Thanks for the feedback.

- henrik