On Fri, May 4, 2012 at 5:05 AM, R.I.Pienaar 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 [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2023 Grokbase