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
--
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.
