On Tuesday, February 18, 2014 6:25:43 AM UTC-6, zerozer...@gmail.com wrote:
>
> On Tuesday, February 18, 2014 1:11:15 PM UTC+1, nikolavp wrote:
>
>
>> class A {
>> service {'myservice':
>> ensure => 'started',
>> }
>>
>> file { '/etc/default/myservice.conf':
>> ensure => present,
>> notify => Service['myservice'],
>> template => '...',
>> }
>> }
>>
>>
>> class B {
>>
>> file { '/etc/default/myservice.conf1':
>> notify => Service['myservice'], # note that this is sort of
>> global
>> template => '...',
>> }
>>
>> Class['A'] -> Class['B']
>> }
>
>
> Uhm, I expected the notify parameter to create a File ~> Service
> dependency, and so a Class['B'] -> Class ['A'] dependency which would
> create a loop with the other one, according to
> http://docs.puppetlabs.com/references/latest/metaparameter.html#notify :
> "[…notify…] it creates a dependency relationship like before".
>
> Does it work instead? Maybe I should just try it. But time's up for today.
>
>
There appears to be some confusion here between evaluation order and
application order. It is true that the code presented contains a
dependency cycle, but it is a needless one. Resource relationships such as
are declared via the chaining operators and the before / require / notify /
subscribe metaparameters influence order of application (on the client),
but have nothing to do with the order of class evaluation during catalog
compilation. Class declarations affect which classes are evaluated and in
what order during catalog compilation, but they do not directly affect the
order in which resources are applied to the target node.
Class B should not declare Class['A'] -> Class['B'], because its
declaration of File['/etc/default/myservice.conf1'] already expresses the
whole application-order relationship between classes A and B. In
particular, it doesn't matter in which order the File resources declared by
those classes are applied. On the other hand, it is good form in cases
like this for class B to 'include' class A because it needs the resources
therein to be declared (but only if class A is not parameterized, or if it
can be assumed to rely on defaults and/or automatic data binding).
With that said, there is some debate over whether it is ever appropriate
for one class to declare relationships directly with *resources* declared
by another. Some argue that declared relationships should never cross
class boundaries, and such a practice yields stability and ease of
maintenance advantages over complete absence of discipline with respect to
which relationships are declared. Personally, though, I take a position
between those extremes. I prefer that relationships not cross class
boundaries, but I'm relaxed about that when the classes involved belong to
the same module.
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/d10f32ef-f42c-4a6e-82e2-725892382168%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
