On Monday, June 30, 2014 8:11:47 PM UTC-5, henrik lindberg wrote: > > Need to correct myself... see below... > > What we cannot predict is what value will be set for realized resources > that have an undef value for an attribute. Those are the only ones that > can be modified with a Resource Override. > >
That doesn't appear to be consistent with the docs <http://docs.puppetlabs.com/puppet/3/reference/lang_resources.html#adding-or-modifying-attributes>. Such a restriction applies in certain cases, but not in the most common ones. In particular, the docs say specifically that the restriction does not apply when subclasses override resources of a superclass, or when resources are overridden via a collector. That was always my understanding, so I'm glad to see the docs backing me up. I never noticed the change allowing overrides in any other cases, but I guess if you use that capability and then are you restricted to assigning values to previously unmanaged properties. Or so say the docs. > If we predict the default, an override may set it to something different > than the default. > > An unrealized resource may be completely overridden, so there you need > to know if it is realized or not to be able to know how well the > prediction will hold for any value. > > No, I think all resources are pretty much in the same boat there, whether realized or not, unless this is something that is being changed in Puppet 4. And I hope it isn't, because the problems that will attend changing the scope of resource defaults pale in comparison with those that would attend changing the rules for resource overrides. We *are* getting rid of dynamic scoping of resource defaults. This has > already been done in 3.7 and is in effect when using the --parser > future. Defaults follow lexical scoping. > > May the almighty have mercy on your souls. In that case, the evaluation-order issues around resource defaults are mostly moot. As the relevant statements will be easily determined and their relative evaluation order readily seen. > > The two cases that we are concerned about is a) the ability to lookup > > resource attribute values, and whether this should return the currently > > known default values or not. We can see it as not looking up default at > > all, or lookup the default values as known at that point in evaluation. > > (Since resource overrides are also in play, and value is actually just a > > prediction), With the narrowed scope that defaults will have, it seems safe and reasonable for lookups to return applicable defaults. > and b) collection of virtual resources since it is unclear > > what default values have been applied and can be queried... > Since defaults will be lexically scoped and eagerly evaluated, I see no reason for excluding collector predicates matching against property values assigned by that means. The results will be predictable, and generally less surprising. John -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5390d0c9-a942-44bc-945c-d0bdd8824499%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
