On Thursday, August 29, 2013 4:59:16 PM UTC-5, François Lafont wrote:
>
> Le 28/08/2013 16:53, jcbollinger wrote :
>
> >> As a result, I have deduced that this code below was correct *and* not
> >> redundant:
> >>
> >> ----------------------------------------
> >> # 1. One declaration.
> >> file { '/usr/local/puppet_host/list':
> >> mode => 440,
> >> content => "List.\n",
> >> }
> >>
> >> # 2. Another one.
> >> File <<| tag == 'exported' |>> {
> >> mode => 0644,
> >> }
> >>
> >> # 3. Ordering.
> >> File['/usr/local/puppet_host/list'] -> File <<| tag == 'exported' |>>
> >> ----------------------------------------
> >>
> >> Am I wrong?
> >>
> >
> >
> > Yes. The code is at least redundant, in that both appearances of
> >
> > File <<| tag == 'exported' |>>
> >
> > specify the inclusion of the matching resources in the target node's
> > catalog, regardless of the fact that they appear in contexts that carry
> > distinct additional implications.
>
> Ok, so if I follow your logic, this simple code below is correct and
> redundant too, isn't it? (and the rendundancy is not a problem)
>
> ----------------------------------------
> # 1. One declaration.
> file {'/tmp/test1':
> ensure => present,
> content => "Hi.",
> }
>
> # 2. Another one.
> notify {'after':
> message => '/tmp/test1 has already been synced.',
> }
>
> # 3. Ordering.
> File['/tmp/test1'] -> Notify['after']
> ----------------------------------------
>
>
No, that is not redundant. Resource references do not direct Puppet to
include the referenced resources in the target node's catalog. Instead,
they depend on those resources being declared by other means, else catalog
compilation will fail.
Collectors are different, partly because they combine two distinct
functions:
1. to realize virtual resources or import exported resources (depending
on the form of the collector), and
2. to serve essentially as a reference to the whole group of collected
resources
It is with respect to the former that collecting the same resources
multiple times is redundant, and ordinary resource references do not serve
that purpose.
Nevertheless, I'm really just trying to rationalize the odd behavior you
observed. I would not have expected your original code to exhibit the
problems it did, and I think it would be better for Puppet to behave as you
expected in this regard.
> Me too. Don't you think that it can be interpreted as a little bug? (or
> just a inconsistency?)
>
Yes, I think it would be reasonable to interpret the behavior as buggy. I
think you would be justified in filing a bug ticket with PuppetLabs over
this. There might even be one already; I didn't check.
>
> It's very curious, if I just change the title of the exported files,
> then the order is as we expect (I give an example in my message #2).
>
>
I think that's just luck. Your original code clearly does not result in
the desired ordering relationship being included in the node's catalog.
Where relationships do not constrain the relative order of two resources,
Puppet is free to apply them in either order. In practice, it uses an
order that is essentially unpredictable, but that remains stable *provided
that the affected resources do not change*. Changing resource titles,
however, can result in a different order of application.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
