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 puppet-dev+unsubscr...@googlegroups.com. 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.
