On 2014-07-22 00:28, Nan Liu wrote:
On Mon, Jul 21, 2014 at 2:30 PM, John Bollinger
<john.bollin...@stjude.org <mailto: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.
I like #3, but despair when thinking about the easy failure modes
(accidentally overwriting a metaparam with something completely different).
Maybe the way forward lies in treating the different kinds of metaparams
- as John has enumerated - also differently:
* "must be forwarded in order to be effective ('tag', 'noop', ...)":
These should not be overrideable. If someone further up has
set noop, nobody should be able to escape that (what about
collections in this dynamic scope? *shudder*)
Trying to have a define or class with such a parameter should be an
error.
* "aren't (or shouldn't) be forwarded, mainly 'alias'":
Either it's allowable to override those, then remove the warning.
OR it's not allowed, then fail with an error.
Personally, I don't think 'alias' should be overrideable, but I have
no argument for that.
* "relational metaparameters could technically swing either way, but
the overall semantics need to maintain containment": This could
definitely be overridable, the user should be aware that he's
expected to maintain the semantics.
Regards, David
--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt
--
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/53CE058C.4040006%40dasz.at.
For more options, visit https://groups.google.com/d/optout.
