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