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) --- 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. 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. 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. 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. 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. 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 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? 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. 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. 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. 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. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
