On Monday, July 7, 2014 9:39:06 AM UTC-5, henrik lindberg wrote:
>
> On 2014-07-07 15:43, John Bollinger wrote:
> [...] Consider:
> >
> > class mymodule {
> > File { group => 'example' }
> > }
> >
> > class mymodule::example {
> > file { '/tmp/example': owner => 'root', ensure => 'file' }
> > }
> >
> > include 'mymodule::example'
> > include 'mymodule'
> >
> > File { mode => '0400' }
> >
> >
> > What should File['/tmp/example']['group'] be? And
> > File['/tmp/example']['mode']?
>
> The evaluation will evaluate both classes before the default expression.
> The resources are thus created before the default is added. If we do go
> for eager defaults, then the two resources would not get an default
> values.
>
>
Ok, that's what I expected, but take a closer look at the classes.
Class[mymodule] declares a resource default for the File resource, and
Class[mymodule::example] declares a file instance, but the later is
'include'd before the former. I am supposing that with eager defaults, the
File instance in Class[mymodule::example] will not see the resource default
this way, but that it would see it if the order of the 'include' statements
were reversed (following the same resolution rules as for variables).
That reversing the order in which the classes are evaluated could change
which defaults are applied -- if indeed that's the case -- would be an
unhappy consequence.
> > If part of the objective is to avoid
> > binding defaults late without (re)opening the door to issues around
> > evaluation order uncertainty, then you can rely only on the local
> > lexical scope for defaults. And yes, variable references do suffer from
> > that issue already.
> >
> > I agree
> > that this pretty much renders defaults useless as they have to be
> > global
> > or repeated per class / define. It is only useful if a define or
> class
> > creates many resources.
> >
> > If defaults followed lexical scope / (namespaces). Then the defaults
> > would apply to the namespace it is defined in, and all inner
> > namespaces..
> > That would make them more useful while also safe to use. They would
> not
> > apply to something that is included.
> >
> >
> >
> > It's not clear to me how that last alternative differs from the previous
> > one, nor whether it fares any better on the evaluation-order front
> > relative to my example above.
>
> If we do defaults per named scope and not do late binding, care has
> to be taken to introduce entities in the right order (to get them
> evaluated in the wanted order - you want to evaluate nested named
> elements after outer elements. This is probably just as confusing to
> puppet users as the current way.
>
>
I'm still not catching the distinction between that and resolving defaults
"how variables are resolved". Probably I'm just being dense, but perhaps I
don't know how variables are resolved as well as I think I do.
In any case, though, it looks like you concur with me that there are
evaluation-order consequences attending these approaches.
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/b5587f04-9c93-4eef-9c8c-d2360b7e2b2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
