Puppet users - Nov 2009 - 0.25.1 require function not working properly?

Shouldn''t this work?

class nginx {
    package { "nginx" : ensure  => present }
    service { "nginx" :
        ensure => running,
        require => Package["nginx"];
    }
}

class my-nginx {
        require nginx
                  file { "/etc/nginx/nginx.conf" :
                        ensure  => present,
                        source   =>
"puppet:///my-nginx/my-nginx.conf",
                        notify  => Service["nginx"],
                }
}

node "my-node" {
include my-nginx
}

But I get :
err: Could not apply complete catalog: Found dependency cycles in the
following relationships: File[/etc/nginx/nginx.conf] =>
Service[nginx], Service[nginx] => File[/etc/nginx/nginx.conf]; try
using the ''--graph'' option and open the
''.dot'' files in OmniGraffle or
GraphViz

If I comment out the notify it works :-(

Thanks,

Matt

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> err: Could not apply complete catalog: Found dependency cycles in the
> following relationships: File[/etc/nginx/nginx.conf] =>
> Service[nginx], Service[nginx] => File[/etc/nginx/nginx.conf]; try
> using the ''--graph'' option and open the
''.dot'' files in OmniGraffle or
> GraphViz
>
> If I comment out the notify it works :-(
the problem is that require implies that every resource in this class  
has to be satisfied before the current class is evaluated, which means  
more or less that every resource in the class my-nginx gets a require  
on the class nginx and its resources.  The behavior you encounter is  
explicitly documented as a warning on [1]. So it works properly and  
your problem is even documented.
What you need to do is to change the require into an include and  
require the package for the file and still notify the service. Like  
that your file definition will be waved into the dependency graph  
between package and service, hence the ordering is correct.

cheers pete

[1] http://reductivelabs.com/trac/puppet/wiki/FunctionReference#require

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Apologies, I didn''t notice the wiki had been updated.

I''d expect that behaviour if using a before, but really think a notify
shouldn''t cause such a dependency, as i''m only asking for a
restart/reload.  That''s just my two pence worth.

I''ll go back to using includes.

Thanks,

Matt

2009/11/2 Peter Meier <peter.meier@immerda.ch>:
>
>> err: Could not apply complete catalog: Found dependency cycles in the
>> following relationships: File[/etc/nginx/nginx.conf] =>
>> Service[nginx], Service[nginx] => File[/etc/nginx/nginx.conf]; try
>> using the ''--graph'' option and open the
''.dot'' files in OmniGraffle or
>> GraphViz
>>
>> If I comment out the notify it works :-(
>
> the problem is that require implies that every resource in this class
> has to be satisfied before the current class is evaluated, which means
> more or less that every resource in the class my-nginx gets a require
> on the class nginx and its resources.  The behavior you encounter is
> explicitly documented as a warning on [1]. So it works properly and
> your problem is even documented.
> What you need to do is to change the require into an include and
> require the package for the file and still notify the service. Like
> that your file definition will be waved into the dependency graph
> between package and service, hence the ordering is correct.
>
> cheers pete
>
> [1] http://reductivelabs.com/trac/puppet/wiki/FunctionReference#require
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> I''d expect that behaviour if using a before, but really think a
notify
> shouldn''t cause such a dependency, as i''m only asking for
a
> restart/reload.  That''s just my two pence worth.
well a notify also implies a before on the notified resource. As you  
want to manage a resource only once per run, you also want to trigger  
a resource only once. So if you want to notify a resource you want the  
resource to be managed after the notifying resource, hence it should  
be managed before. In your example this means that if the file likes  
to notify the service it have to be managed before.

Otherwise the service is for example in one run first started and then  
later restarted, which isn''t something you''d like to have.

Makes sense, doesn''t it?

cheers pete

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

I see the logic in your explanation, I just don''t think it adds up
when evaluating when to use a before or notify.

A notify for me says run this resource again, or schedule it to be run
again (it may be scheduled by other classes).  I don''t see why it
would also imply a before.  If I don''t mind if the service starts and
then in seconds get''s restarted/reloaded then I would happily use a
notify, otherwise I would use a before and understand that I need to
include a class rather than require it.  It''s all still going to be
within the first catalogue run.

Why wouldn''t I want a resource to be managed multiple times in one run?

2009/11/2 Peter Meier <peter.meier@immerda.ch>:
>
>> I''d expect that behaviour if using a before, but really think
a notify
>> shouldn''t cause such a dependency, as i''m only asking
for a
>> restart/reload.  That''s just my two pence worth.
>
> well a notify also implies a before on the notified resource. As you
> want to manage a resource only once per run, you also want to trigger
> a resource only once. So if you want to notify a resource you want the
> resource to be managed after the notifying resource, hence it should
> be managed before. In your example this means that if the file likes
> to notify the service it have to be managed before.
>
> Otherwise the service is for example in one run first started and then
> later restarted, which isn''t something you''d like to
have.
>
> Makes sense, doesn''t it?
>
> cheers pete
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

> A notify for me says run this resource again, or schedule it to be run
> again (it may be scheduled by other classes).
you don''t run resources, you manage resources. It is a fundamental  
concept of puppet that you don''t execute a bunch of scripts, instead  
you describe the state of your infrastructure and let puppet do the  
necessary steps to fulfill this state.
> Why wouldn''t I want a resource to be managed multiple times in one
run?
because you describe the state of your infrastructure with your  
manifests, hence you describe the state of your resources and this  
state can''t really change various times during the run. What puppet  
does is a transition of the resource from the current state into the  
described, expected state and this transition is done at the point  
when the resource is managed, the point when puppet arrived at the  
resource while traversing the graph.
I agree that you might still say: Well what I''m interested in - and  
this is what I still describe in my manifests - is the state at the  
end of a puppet run. However if you think about all the other  
resources that can receive a notify - especially the exec resource -  
you end up very quickly finding a lot of more complex situations if a  
before isn''t implied by a notify.

cheers pete

ps: this is just my point of view how I think that puppet works and I  
think it''s good that it works that way. But it''s not the only
truth
out there... And I''m always open to other ideas.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

>> A notify for me says run this resource again, or schedule it to be run
>> again (it may be scheduled by other classes).
>
> you don''t run resources, you manage resources. It is a fundamental
> concept of puppet that you don''t execute a bunch of scripts,
instead
> you describe the state of your infrastructure and let puppet do the
> necessary steps to fulfill this state.
s /run/manage/g
>> Why wouldn''t I want a resource to be managed multiple times in
one run?
>
> because you describe the state of your infrastructure with your
> manifests, hence you describe the state of your resources and this
> state can''t really change various times during the run. What
puppet
> does is a transition of the resource from the current state into the
> described, expected state and this transition is done at the point
> when the resource is managed, the point when puppet arrived at the
> resource while traversing the graph.
> I agree that you might still say: Well what I''m interested in -
and
> this is what I still describe in my manifests - is the state at the
> end of a puppet run. However if you think about all the other
> resources that can receive a notify - especially the exec resource -
> you end up very quickly finding a lot of more complex situations if a
> before isn''t implied by a notify.
I think its still valid to be able to use it this way, especially in
the case of a notify, when multiple resources can issue a notify, but
the action of the notify only has to happen once when those resources
are completed.  I can see situations with over types where this may
not apply, and the exec example you give supports the current
behaviour well.  But we want to do less exec''s though, as
that''s just
scripts :-)
> ps: this is just my point of view how I think that puppet works and I
> think it''s good that it works that way. But it''s not the
only truth
> out there... And I''m always open to other ideas.
Discussions like this only add value.  Seeing or doing a module of
when a require class would be more beneficial then an include class
would probably help me see the value in this feature.

Matt

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---