Puppet users - Dec 2012 - Multiple Requires not allowed, not sure what this is for...

I''m having a case where, as with Puppet, multiple packages use the same
file.  For example, puppet and puppetmaster both use /etc/puppet/puppet.conf

My first attempt was to have a class ''puppet::client'' include
a service
''puppet'' with a require =>
Class["puppet::config"], as well a class
''puppet::client'' include a service
''puppetmaster'' with a require =>
Class["puppet::config"]

Problem:  Can''t do that. Running across the same require for a class
twice
gets an error.

It''s not particularly important that the server or client get executed 
first, as long as the config is executed first.  That''s what the whole 
require thing is for, right?


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/6sb4p4AD0jIJ.
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.

Hi John!

On Fri, Dec 21, 2012 at 08:36:27PM -0800, John Moser
wrote:
> I''m having a case where, as with Puppet, multiple packages use the
same
> file.  For example, puppet and puppetmaster both use
/etc/puppet/puppet.conf
You can declare a list of requires for a resource. Something like:

  service { ''postgresql'':
    ensure  => running,
    require => [
      File[/etc/postgresql/9.1/main/postgresql.conf],
      Package[postgresql]
    ]
  }

Both file and package are handled first and need to be in the catalog.

I use this often, when I have some module that has a dependency on e.g.
Service[apache2], but does not deal with that on it''s own. Puppet
ensures then
that the webserver is declared in the catalog and the vhost I am
concerned with has no problems.

Cheers,
Matthias Viehweger
-- 
Serververwaltung und Softwareentwicklung
 
https://www.heute-kaufen.de
Prinzessinnenstraße 20 - 10969 Berlin

On Friday, December 21, 2012 10:36:27 PM UTC-6, John Moser
wrote:
>
> I''m having a case where, as with Puppet, multiple packages use the
same
> file.  For example, puppet and puppetmaster both use
/etc/puppet/puppet.conf
>
> My first attempt was to have a class ''puppet::client''
include a service
> ''puppet'' with a require =>
Class["puppet::config"], as well a class
> ''puppet::client'' include a service
''puppetmaster'' with a require =>
> Class["puppet::config"]
>
> Problem:  Can''t do that. Running across the same require for a
class twice
> gets an error.
>

No, that''s not your problem.  Any number of classes or resources may 
''require'' a given class or resource.  Similarly for the other
types or
relationships.  Also the same for relationships declared via the chain 
operators, implied by run stages, or inherited from a declaring class.

 
>
> It''s not particularly important that the server or client get
executed
> first, as long as the config is executed first.  That''s what the
whole
> require thing is for, right?
>
>
>
Yes, you understand the concept. You have not provided enough information 
for me to confidently identify the problem, but my first guess would be 
that it is a parse order issue.  Your manifests must not reference classes 
or resources (e.g. "Class[''puppet::config'']") whose
declarations have not
yet been parsed.  There are several ways to ensure a suitable parse order 
(as distinguished from the entirely separate client-side order of resource 
application).

Supposing that class ''puppet::config'' is not parametrized, the
easiest
thing to do would be to use the ''require'' function (not the
resource
metaparameter) to declare class ''puppet::client''''s
parse- and
application-order dependency on class ''puppet::config''.  It
would look like
this:

class puppet::client {
  require ''puppet::config''

  # ... other declarations
  #
  # resources declared directly
  # by this class do not need to
  # declare any relationship to
  # class ''puppet::config'' (though
  # it is harmless for them to do)
}

Alternatively, you can use ''include'' instead of
''require'' if you intend for
each resource to continue to declare its own dependencies, or if you have 
other resources in class ''puppet::client'' that do not need a
relationship
with class ''puppet::config''.

You may also want to consider whether you want to establish relationships 
with the config class, or whether it would be as good or better to 
establish them with particular resources declared by that class (e.g. 
File[''/etc/puppet/puppet.conf'']).  There are a few other
variations and
options as well, and you are more constrained if class
''puppet::config'' is
parametrized, but maybe this will get you looking in the right direction.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/B4IH43KY1uMJ.
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 Wednesday, January 2, 2013 4:33:36 PM UTC+1, jcbollinger wrote:
> You may also want to consider whether you want to establish relationships 
> with the config class, or whether it would be as good or better to 
> establish them with particular resources declared by that class (e.g. 
> File[''/etc/puppet/puppet.conf'']).  There are a few other
variations and
> options as well, and you are more constrained if class
''puppet::config'' is
> parametrized, but maybe this will get you looking in the right direction.
>
We make a habit of only depending on individual resources (File etc.) 
within a single class. Dependencies outside the class (e.g. in another 
manifest) are on classes only. Not sure if others agree, but we made this 
choice so we could move resources around within a class, clean up code, 
change File { "path": to File { "name": etc.

Best,

Hans van der Made
Utrecht University
NL 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/845UwF-GQjIJ.
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 12/22/2012 05:36 AM, John Moser wrote:
> I''m having a case where, as with Puppet, multiple packages use the
same
> file.  For example, puppet and puppetmaster both use
/etc/puppet/puppet.conf
I''ve approached this problem in another way.

I define file puppet.conf in puppet class, and override it in class 
puppet::master, which inherits puppet. So, my master(s) use different 
template, and still configure the config file for agents on the master 
machines, too.


-- 
Jakov Sosic
www.srce.unizg.hr

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.