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 [email protected].
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.
