On Mon, Jul 21, 2014 at 2:30 PM, John Bollinger <john.bollin...@stjude.org>
wrote:
>
>
> On Monday, July 21, 2014 3:32:47 PM UTC-5, Nan Liu wrote:
>
>> Similar to the discussion of collect resources realize + override, I wish
>> the metaparameters weren't magically passed to the resources, and we could
>> choose to use them and pass the behavior on as needed.
>>
>>
>
> Sadly, it's not that easy. Some metaparameters already aren't (or
> shouldn't) be forwarded, mainly 'alias'. On the other hand, many others
> *must* be forwarded in order to be effective ('tag', 'noop', ...). The
> relational metaparameters could technically swing either way, but the
> overall semantics need to maintain containment.
>
> Schedule and loglevel are the only two that I think are ambiguous, but
> more loglevel than schedule. I'm not sure how it makes sense for a
> resource to not inherit the schedule set on its container (if there is
> one), else it's container's assigned schedule isn't fully honored. On the
> other hand, it does make sense for a resource to have a different (lower)
> loglevel than its container, especially if the container's is interpreted
> as an upper bound rather than an exact log level for all messages.
>
The warning message seems to be a sign the behavior is not well defined
which leaves much to be desired. I was hoping there was some path forward:
1. Not supported, don't reuse metaparameter as class parameter. Deprecate
it, and enforce with failure.
2. Supported, metaparameter as class parameter pass behavior to contained
resources. In this scenario, I would argue metaparameter should be allowed
without being specified as a class parameter explicitly (see ticket).
https://tickets.puppetlabs.com/browse/PUP-2556
3. Supported, metaparameter as class parameter behavior is configured by
user, support is enabled by specifying the parameter.
I'm not sure what are the other solutions beyond the three above, but
removing the ambiguity we have now would be an improvement.
Nan
--
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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CACqVBqDm0-wXe6XffLG8ZVrOsJqejKhCC5Y1ev8n2b4tbH9GtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
