err: Could not apply complete catalog: Found 1 dependency cycle:

[omfg9899]

Puppet Version : 2.7.25

 So I don't get it at all..

<snip>

err: Could not apply complete catalog: Found 1 dependency cycle:

(Exec[chown_logdir] => Class[Jetty] => User[evolve] => Exec[chown_logdir])

Cycle graph written to /var/lib/puppet/state/graphs/cycles.dot.

</snip>

<Cycle graph>

digraph Resource_Cycles {

  label = "Resource Cycles"

"Exec[chown_logdir]" -> "Class[Jetty]" -> "File[/mnt/jetty-logs]" -> "File[/opt/jetty/current/logs]" -> "Class[Jetty]"

"Exec[chown_logdir]" -> "Class[Jetty]" -> "User[evolve]" -> "Exec[chown_logdir]"

</Cycle graph>

 I get past some other crazy ignorant issues only to be faced with one that I find even more miserable..

"err: Could not apply complete catalog: Found 1 dependency cycle:"

  I have tried to break this down to make sense, but I can't make heads or tails of it..  The worse part is that it worked fine with an earlier version of puppet.. 

 There are a couple of pieces of declarations that I think have something to do with it..

<code>

  exec {'remove_original_logs_dir':
command => 'rm -rf /opt/jetty/current/logs',
path => '/bin/',
require => File["$jetty_home/current"],
before => File['/opt/jetty/current/logs'],
}  

  file {'/opt/jetty/current/logs':
ensure => link,
target => '/mnt/jetty-logs',
require => File["$jetty_home/current"],
}

</code>

  If I remove the second of these two, where it creates the synlink, this error goes away.  I do however need that symlink to exist..

  Thanx in advance for any help...

J

[jcbollinger]

On Monday, September 29, 2014 5:28:18 AM UTC-5, omfg9899 wrote:

Puppet Version : 2.7.25

 So I don't get it at all..

<snip>

err: Could not apply complete catalog: Found 1 dependency cycle:

(Exec[chown_logdir] => Class[Jetty] => User[evolve] => Exec[chown_logdir])

Cycle graph written to /var/lib/puppet/state/graphs/cycles.dot.

</snip>

<Cycle graph>

digraph Resource_Cycles {

  label = "Resource Cycles"

"Exec[chown_logdir]" -> "Class[Jetty]" -> "File[/mnt/jetty-logs]" -> "File[/opt/jetty/current/logs]" -> "Class[Jetty]"

"Exec[chown_logdir]" -> "Class[Jetty]" -> "User[evolve]" -> "Exec[chown_logdir]"

</Cycle graph>

 I get past some other crazy ignorant issues only to be faced with one that I find even more miserable..

I'm sorry that you are having difficulties.  I am not impressed by your attitude.

Despite my better judgement, I am going to try to help you anyway.

 

"err: Could not apply complete catalog: Found 1 dependency cycle:"

  I have tried to break this down to make sense, but I can't make heads or tails of it..  The worse part is that it worked fine with an earlier version of puppet.. 

Puppet chooses an acceptable order in which to apply resources with with respect to the "relationships" between them, including those you declare explicitly, and typically also some that Puppet identifies automatically.  (As an example of the latter, if you are managing both File['/foo'] and File['/foo/bar'], then Puppet will automatically use File['/foo'] -> File['/foo/bar'] unless you explicitly tell it otherwise.)  The explicit relationships are specified in your manifests via the chain operators (e.g. ->), via the 'require', 'before', 'subscribe', and 'notify' resource metaparameters, and/or via the 'require' statement/function (in modern Puppet there is also the 'contain' statement/function, but that does not pertain to you).

It is possible for you to declare two or more resources and a set of relationships such that there is no order in which the resources can be applied that complies with all the relationships among them.  This is called a "dependency cycle" because if you follow the chain of dependencies described by the relevant resource relationships then you eventually return to the resource from which you started.  When Puppet encounters such a situation it takes a conservative course and bails out.  That's as it should be: it is far better to decline to configure the target machine than to risk misconfiguring it.

 

 There are a couple of pieces of declarations that I think have something to do with it..

<code>

  exec {'remove_original_logs_dir':
command => 'rm -rf /opt/jetty/current/logs',
path => '/bin/',
require => File["$jetty_home/current"],
before => File['/opt/jetty/current/logs'],
}  

  file {'/opt/jetty/current/logs':
ensure => link,
target => '/mnt/jetty-logs',
require => File["$jetty_home/current"],
}

</code>

The error message describing the cycle(s) tells you exactly which resources are involved, and therefore which declarations to consider.  The first of the declarations you presented is not among the resources involved in either of the cycles you described.  The second is involved in one of them.

 

  If I remove the second of these two, where it creates the synlink, this error goes away.  I do however need that symlink to exist..

Yes, it is to be assumed that the resource is declared because you need to have it.  The solution to a dependency cycle issue is not to remove resources from the catalog; it is simply to change or remove the relationships among them to eliminate the conflict.

You can start by removing the 'require' parameter from File['/opt/jetty/current/logs'].  If the value of $jetty_home happens to be "/opt/jetty" and you are also managing File['/opt/jetty/current'] then Puppet will create that relationship automatically; otherwise you don't need it.  In all likelihood that will not solve this particular problem, however, because I don't think the main issue is in that declaration.

Let's start with the whole body of class "jetty", which I suppose probably includes the two declarations you already presented, and likely others.  Also, if any of your manifests contains a reference to that class (i.e. the form "Class['Jetty']") then the declarations containing those are also relevant.


John

[omfg9899]

  Not sure what about my attitude you do not like.. /me scratches head.. But anyway.

 Everything you have posted is accurate and when I took a closer look at "graph" output I realized that something was trying to set the permissions on the log directory a second time.  After some searching I located the conficlited code, consolidated them into one file and everything works now..   I am off dealing with other problems from the upgrade now. :D

 Thanx for your time,

 J