Puppet users - Jun 2011 - Using require and notify across class resources cause a dependency cycle

I have a simple sample below that illustrates a problem I ran into
today.  What I am trying do is execute a command only if another
class, that which is dependent on it''s class, triggers the command
with a notify.  I''m using the refreshonly => true to prevent it from
running unless something triggers it.  The require is needed because
other things need to be done in class a before class b.

When I run this code I get the following error message:

err: Could not apply complete catalog: Found dependency cycles in the
following relationships

Am I doing something wrong?

I think my only solution is to move the Exec[a] out of class a but I
would think that this should work...

Thanks,

John

class a {
   exec { ''a'':
      command => ''echo "This is a test file and can be deleted
(Exec[a])" > /tmp/puppet-test2.txt'',
      refreshonly => true,
   }
   # .... some other commands
}

class b {
   file { ''/tmp/puppet-test1.txt'':
      content => ''This is a test file and can be deleted
(File)'',
      require => Exec[''a''],
      notify  => Exec[''a'']
   }
}

include a
include b

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jun 22, 4:27 pm, PBWebGuy <pbweb...@gmail.com>
wrote:
> I have a simple sample below that illustrates a problem I ran into
> today.  What I am trying do is execute a command only if another
> class, that which is dependent on it''s class, triggers the command
> with a notify.  I''m using the refreshonly => true to prevent it
from
> running unless something triggers it.  The require is needed because
> other things need to be done in class a before class b.
>
> When I run this code I get the following error message:
>
> err: Could not apply complete catalog: Found dependency cycles in the
> following relationships
>
> Am I doing something wrong?

Yes.  Your scenario does not make sense: if Class[''b'']
requires
Class[''a''], then each resource in Class[''b'']
requires every resource
in Class[''a''], by definition.  Therefore, if any resource in
Class[''b''] also has a ''notify'' or
''before'' relationship with a
resource in Class[''a''] then that closes a dependency cycle. 
(''Notify''
is ''before'' plus a few extra bits.)

> I think my only solution is to move the Exec[a] out of class a but I
> would think that this should work...

That''s perhaps the least disruptive solution, but by no means the only
one.  There are all sorts of ways you could refactor your
dependencies.  Among them, you could replace the inter-Class
dependency with the needed inter-resource dependencies, which
evidently are a subset of those implied by your intercalss
dependency.  Dependency cycles often do signal classification
problems, however, and I think that''s probably the case here.

While I''m on my soapbox, this is one reason why I don''t like
interclass dependencies very much, and why run stages (which magnify
this problem) need to be approached with caution.  There is certainly
something to be said for the layer of abstraction achieved by relying
on interclass dependencies instead of on finer-grained inter-resource
dependencies, but you can''t do it halfway.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jun 23, 2011 at 6:01 AM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
> While I''m on my soapbox, this is one reason why I don''t
like
> interclass dependencies very much, and why run stages (which magnify
> this problem) need to be approached with caution.  There is certainly
> something to be said for the layer of abstraction achieved by relying
> on interclass dependencies instead of on finer-grained inter-resource
> dependencies, but you can''t do it halfway.
>
I agree with the halfway bit :) but generally I feel that class-to-class
relationships are much easier to maintain than resource-to-resource
relationships that cross class boundaries.

It allows you to change the internal relationships and behavior of classes
without worrying so much about external consumers of your class.
Encapsulation is a good thing.

Your modules are significantly less reusable if you need to document
required individual resource relationships.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jun 23, 9:54 am, Nigel Kersten <ni...@puppetlabs.com>
wrote:
> On Thu, Jun 23, 2011 at 6:01 AM, jcbollinger
<John.Bollin...@stjude.org>wrote:
>
>
>
> > While I''m on my soapbox, this is one reason why I
don''t like
> > interclass dependencies very much, and why run stages (which magnify
> > this problem) need to be approached with caution.  There is certainly
> > something to be said for the layer of abstraction achieved by relying
> > on interclass dependencies instead of on finer-grained inter-resource
> > dependencies, but you can''t do it halfway.
>
> I agree with the halfway bit :) but generally I feel that class-to-class
> relationships are much easier to maintain than resource-to-resource
> relationships that cross class boundaries.
>
> It allows you to change the internal relationships and behavior of classes
> without worrying so much about external consumers of your class.
> Encapsulation is a good thing.

I quite agree that encapsulation is a good thing, but it is
impractical to expect rigorous encapsulation in Puppet''s problem
domain.  System configuration does not break up neatly along any
hierarchical lines I have ever considered, so there are many non-
trivial questions of which class should own which resource, and of how
non-owning classes can express their own requirements.  The OP''s
problem is evidently an example.

Furthermore, remember that Puppet resources all have global scope,
regardless of where they are declared, so Puppet classes and modules
provide rather incomplete encapsulation anyway.  Their greatest
usefulness is instead in the layer(s) of *abstraction* they embody.

Right now, the main advantages of prefering resource-level
relationships are a lower likelihood of dependency cycles, and a
clearer path to resolving any that arise.  As Puppet development
continues, however, avoiding unnecessary relationships among resources
could conceivably facilitate useful optimizations, such as combined
application of multiple Package resources.  Though presently Puppet
itself may not do much with it, in general, the more freedom one can
afford to an expert system, the better.

> Your modules are significantly less reusable if you need to document
> required individual resource relationships.

Given that Puppet permits resources to be managed only in one place,
reusable modules need to thoroughly document all the resources they
manage anyway, or at least to document an exclusive claim to an
appropriate swath of resources.  How reusable you can hope a module
will be depends greatly on how diverse the demands are on the
resources it manages.


Cheers,
John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.