On 2014-22-07 8:32, David Schmitt wrote:
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.
To me puppet's meta parameters, are just like other attributes of an
object and have traits; readable, writable, virtual, derived,
multiplicity, data-type, private, final, volatile.
Without having a way of specifying the contract for a meta parameter how
does subclasses know what they should implement? How can this be
tested/enforced?
Some of the listed traits cannot be implemented in the Puppet Language;
it is not possible to pass on a call to a "super parameter
implementation", we cannot do before/after/around (we only have
instead-of), we have very small means of specifying logic to run late in
the lazy evaluation, all of the information required to implement some
meta parameter behaviors is not available until after we stopped
evaluating the puppet logic.
Currently the only thing we can do with some sort of safety is to make
them final. (i.e. option number 1).
BTW; the "meta-like" parameters $name and $title have been blocked in
the future parser (they raise an error), so you can say we made them final.
Later, it may be possible to use the Puppet Type system, to declare that
a parameter is of a type derived from a MetaParameter type. This because
it will be possible to define behavior for types (i.e. data types / not
resource types). At that point, it is possible to have a richer set of
traits available in the Puppet Language and we can remove the final
restrictions on those meta parameters where it makes sense (i.e. option
#3 with David S's addition).
The above means, that in order for a Class to re-implement a
meta-parameter, that parameter needs to refer to a defined type, that in
turn declares that it is derived from the meta-data-type in question.
type MySchedule inherits MetaParameter[Schedule] {
# The stuff that needs to be done for the derived schedule
}
class myclass(MySchedule $schedule) {
}
Not typing it to be a kind of Schedule breaks the contract, and that
would be an error.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/lqlmi0%24lcn%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
