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
On Monday, September 29, 2014 9:21:16 AM UTC-5, jcbollinger wrote:
>
>
>
> 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 *mis*configuring 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
>
>
--
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/4c384086-87a6-4b21-a6fa-678f06f29d38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
