On Fri, May 4, 2012 at 5:05 AM, R.I.Pienaar <r...@devco.net> wrote:
>
> I think the plan was that there would be a priority order as below:
>
> - someone wrote in a manifest: class{"foo": something => something}
> - an ENC supplied the values for something on the class foo
> - someone did "include foo" or class{"foo": } this would consult hiera
> - if hiera does not have an answer it would default to "default"
>
> This gives people with more complex needs than those matched by hiera
> the ability to use ENCs and get exactly the data model they desire as
> well as people who do not want any magical data lookup for some class
> the ability to hard code values.
>
> And at the same time it lets module authors provide out of the box
> defaults that work without placing a load on module users where they
> might have to read every class and set hiera values for every argument
> before they can use a class if all they wanted was the default out of
> the box behaviour.
>
> Does this sound sane?
I can't speak for anyone else but this sounds fantastic to me. I've already
ran into this problem where I want a bunch of defaults to be used unless
they need to specifically overwrite them in Hiera and I don't always want
to add those into Hiera (because of the lack of namespacing it can get
messy). All of the changes mentioned so far will be of very big benefit
and really improve things. :)
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
