On Tuesday, April 9, 2013 2:35:07 PM UTC-5, Mike Power wrote:
>
> Have anyone of you every seen puppet invert a dependency?
>
>
> Say I have a class like so:
> class jenkins {
> user {"jenkins":
> ensure => present,
> }
> }
>
> That should form a dependency like so User[jenkins] => Class[jenkins].
> That dependency means that the user jenkins will be done before Class
> jenkins. However every once (twice now) something disturbs pupplets
> delicate sensibilities and it seems to create a new dependency that goes
> backward from what it is supposed to. This causes a dependency cycle and
> breaks my catalog. Right now I have a git module checking out the source
> for a jenkins server. I end up with a dependency cycle like this:
> (Exec[git_http://[email protected]/somevalidgiturl] => Git::Repo[
> http://[email protected]/somevalidgiturl] => Class[Jenkins] =>
> User[jenkins] => Exec[git_http://[email protected]/somevalidgiturl])
>
> Notice how it now says Class[Jenkins] needs to be done before
> User[jenkins]. But the jenkins user is defined in the class jenkins. So
> the dependency should be the other way, It seems to have inverted that
> dependency. I have found that if I tweak with related components of the
> catalog then it will go away.
>
> https://projects.puppetlabs.com/issues/19718
>
I agree that it is odd for Puppet to be inconsistent about the direction of
the dependency, but it's not necessarily wrong. On the client side,
applying a class itself is a no-op, so where that comes in the overall
sequence doesn't matter. To the extent that you consider the class to be a
container for the resources declared within, neither before nor after is
quite right -- the class should really be *around* the resources, but
Puppet does not have a way to represent that directly. Nevertheless,
relationships declared for a class are inherited by the resources declared
directly within (except other classes, if you consider those resources), so
the kind of flip flop you observe should not be problematic. If it bothers
you then you should be able to achieve a consistent order by declaring it
explicitly.
What can be an issue is when a class declares one or more others. It is
sometimes -- but by no means always -- the case that the desired result is
for relationships with the declaring class be inherited by the other
classes it declares. This can be achieved by applying the "anchor"
pattern. That can be viewed as creating synthetic resources representing
the boundaries of the class, thereby providing a sense in which the
containing class can indeed be applied "around" resources and other classes.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
