Puppet users - Oct 2010 - Variable of define is used more than once

Hello,

i am using "puppet 0.25.4" at "debian 5.0.6" and have
noticed, that the
"puppet" or "puppetmaster" process sometimes is dying. Of
course i could
use the "cron" instead of the "deamon", but i have decided
to write a
module for "monit".

To make this module much dynamic as possible, it is using a define which
will be called at several other modules to ship out a service specific
config file.

In this case the variable "$name" is used more than once and other
hosts
are getting the file "puppetmaster". I am pretty sure that this is my
fault, but at this point i did not see a solution. Please, give me a hint.

BTW: I would love to see that Puppet Labs is offering his own packages,
like VirtualBox or other companies, because the Debian packages are
often out-of-date.

Regards, Dennis

On Wed, Oct 13, 2010 at 12:31 AM, Dennis Hoppe
<dennis.hoppe@debian-solutions.de> wrote:
> Hello,
>
> i am using "puppet 0.25.4" at "debian 5.0.6" and have
noticed, that the
> "puppet" or "puppetmaster" process sometimes is dying.
Of course i could
> use the "cron" instead of the "deamon", but i have
decided to write a
> module for "monit".
>
> To make this module much dynamic as possible, it is using a define which
> will be called at several other modules to ship out a service specific
> config file.
>
> In this case the variable "$name" is used more than once and
other hosts
> are getting the file "puppetmaster". I am pretty sure that this
is my
> fault, but at this point i did not see a solution. Please, give me a hint.
>
> BTW: I would love to see that Puppet Labs is offering his own packages,
> like VirtualBox or other companies, because the Debian packages are
> often out-of-date.
They are?

http://packages.debian.org/puppet


>
> Regards, Dennis
>


-- 
nigel

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

- lenny (stable) <http://packages.debian.org/lenny/puppet> (admin):
   centralised configuration management for networks
   0.24.5-3: all
   - lenny-backports
<http://packages.debian.org/lenny-backports/puppet>(admin):
centralised configuration management for networks
   0.25.4-2~bpo50+1 [*backports* <http://backports.debian.org/>]: all

Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on "Thu,
24
Jul 2008 10:58:08 +0100". (Days after release, which is good, but over 2
years ago, which is bad..) Looks like 12 releases since then.

0.25.4 was released upstream in January and is -also- not "up to date"
(minor, major, then another minor revs since then..)

On Wed, Oct 13, 2010 at 10:26 AM, Nigel Kersten <nigelk@google.com> wrote:
> > BTW: I would love to see that Puppet Labs is offering his own
packages,
> > like VirtualBox or other companies, because the Debian packages are
> > often out-of-date.
>
> They are?
>
> http://packages.debian.org/puppet
>
>
>
-- 
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 10/13/2010 04:37 PM, Disconnect wrote:
>    - lenny (stable) <http://packages.debian.org/lenny/puppet>
(admin):
>    centralised configuration management for networks
>    0.24.5-3: all
>    - lenny-backports
> <http://packages.debian.org/lenny-backports/puppet>(admin):
> centralised configuration management for networks
>    0.25.4-2~bpo50+1 [*backports* <http://backports.debian.org/>]: all
> 
> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on
"Thu, 24
> Jul 2008 10:58:08 +0100". (Days after release, which is good, but over
2
> years ago, which is bad..) Looks like 12 releases since then.
> 
> 0.25.4 was released upstream in January and is -also- not "up to
date"
> (minor, major, then another minor revs since then..)
What''s with the nitpicking? They call it "Debian stable"
because it is,
well, stable. You get what you choose.

I think the OP suggest that Reductive Labs offer the download of
packages that both
a) will install on Debian (stable?) and
b) offer varying amounts of bleeding-edged-ness.

This idea is not without merit, I might add.

Cheers,
Felix

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

Sure, Debian stable -is- stable, and there is a lot to be said for that.
(Ditto for Ubuntu LTS.) The statement was (somewhat rudely) "they
aren''t
outdated, go here and see". 2+ years counts as "outdated".
Last-major-version and most of a year old is "outdated".

Note that I didn''t reply to the OP, I replied to Nigel''s
sarcasm.

On Wed, Oct 13, 2010 at 10:43 AM, Felix Frank <
felix.frank@alumni.tu-berlin.de> wrote:
> On 10/13/2010 04:37 PM, Disconnect wrote:
> >    - lenny (stable) <http://packages.debian.org/lenny/puppet>
(admin):
> >    centralised configuration management for networks
> >    0.24.5-3: all
> >    - lenny-backports
> > <http://packages.debian.org/lenny-backports/puppet>(admin):
> > centralised configuration management for networks
> >    0.25.4-2~bpo50+1 [*backports*
<http://backports.debian.org/>]: all
> >
> > Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on
"Thu,
> 24
> > Jul 2008 10:58:08 +0100". (Days after release, which is good, but
over 2
> > years ago, which is bad..) Looks like 12 releases since then.
> >
> > 0.25.4 was released upstream in January and is -also- not "up to
date"
> > (minor, major, then another minor revs since then..)
>
> What''s with the nitpicking? They call it "Debian stable"
because it is,
> well, stable. You get what you choose.
>
> I think the OP suggest that Reductive Labs offer the download of
> packages that both
> a) will install on Debian (stable?) and
> b) offer varying amounts of bleeding-edged-ness.
>
> This idea is not without merit, I might add.
>
> Cheers,
> Felix
>
> --
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
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 Wed, Oct 13, 2010 at 11:07:27AM -0400, Disconnect
wrote:
> 
> Note that I didn''t reply to the OP, I replied to Nigel''s
sarcasm.
> 
You could take this up with one of the Debian puppet package
maintainers.  Oh, but then you already have...

-- 
Bruce

I unfortunately do not know how to turn cheese into gold.

-- 
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 Wed, Oct 13, 2010 at 7:43 AM, Felix Frank
<felix.frank@alumni.tu-berlin.de> wrote:
> On 10/13/2010 04:37 PM, Disconnect wrote:
>>    - lenny (stable) <http://packages.debian.org/lenny/puppet>
(admin):
>>    centralised configuration management for networks
>>    0.24.5-3: all
>>    - lenny-backports
>> <http://packages.debian.org/lenny-backports/puppet>(admin):
>> centralised configuration management for networks
>>    0.25.4-2~bpo50+1 [*backports* <http://backports.debian.org/>]:
all
>>
>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on
"Thu, 24
>> Jul 2008 10:58:08 +0100". (Days after release, which is good, but
over 2
>> years ago, which is bad..) Looks like 12 releases since then.
>>
>> 0.25.4 was released upstream in January and is -also- not "up to
date"
>> (minor, major, then another minor revs since then..)
>
> What''s with the nitpicking? They call it "Debian stable"
because it is,
> well, stable. You get what you choose.
>
> I think the OP suggest that Reductive Labs offer the download of
> packages that both
> a) will install on Debian (stable?) and
> b) offer varying amounts of bleeding-edged-ness.
>
> This idea is not without merit, I might add.
Have you tried running the recent packages on Debian stable? They do
work, you''re more than welcome to go to a bleeding edge release if you
wish.

This is all pretty standard practice for Debian...

I wasn''t being sarcastic. I was pointing out the more recent packages
you''re welcome to try.
>
> Cheers,
> Felix
>
> --
> 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.
>
>


-- 
nigel

-- 
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 Wed, Oct 13, 2010 at 10:37:03AM -0400, Disconnect
wrote:
>    - lenny (stable) <http://packages.debian.org/lenny/puppet>
(admin):
>    centralised configuration management for networks
>    0.24.5-3: all
>    - lenny-backports
> <http://packages.debian.org/lenny-backports/puppet>(admin):
> centralised configuration management for networks
>    0.25.4-2~bpo50+1 [*backports* <http://backports.debian.org/>]: all
> 
> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on
"Thu, 24
> Jul 2008 10:58:08 +0100". (Days after release, which is good, but over
2
> years ago, which is bad..) Looks like 12 releases since then.
> 
> 0.25.4 was released upstream in January and is -also- not "up to
date"
> (minor, major, then another minor revs since then..)
Sid has 0.26.0, and experimental has 0.26.1. In my experience 
(admittedly not with 0.26.x) versions from sid have always installed 
fine on current debian stable, otherwise backporting yourself is usually 
fairly easy.

Stu
-- 
From the prompt of Stu Teasdale

Start the day with a smile.  After that you can be your nasty old self again.

-- 
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 Oct 13, 2010, at 8:44 AM, Stu Teasdale wrote:
> On Wed, Oct 13, 2010 at 10:37:03AM -0400, Disconnect wrote:
>>   - lenny (stable) <http://packages.debian.org/lenny/puppet>
(admin):
>>   centralised configuration management for networks
>>   0.24.5-3: all
>>   - lenny-backports
>> <http://packages.debian.org/lenny-backports/puppet>(admin):
>> centralised configuration management for networks
>>   0.25.4-2~bpo50+1 [*backports* <http://backports.debian.org/>]:
all
>> 
>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on
"Thu, 24
>> Jul 2008 10:58:08 +0100". (Days after release, which is good, but
over 2
>> years ago, which is bad..) Looks like 12 releases since then.
>> 
>> 0.25.4 was released upstream in January and is -also- not "up to
date"
>> (minor, major, then another minor revs since then..)
> 
> Sid has 0.26.0, and experimental has 0.26.1. In my experience 
> (admittedly not with 0.26.x) versions from sid have always installed 
> fine on current debian stable, otherwise backporting yourself is usually 
> fairly easy.
This might have been what you meant, but I''ve heard t''s
usually a good idea to pick a version of facter that''s kind of close to
puppets version.  (or newer than puppet''s version)

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

Hello Felix,

Am 13.10.2010 16:43, schrieb Felix Frank:
> On 10/13/2010 04:37 PM, Disconnect wrote:
>>    - lenny (stable) <http://packages.debian.org/lenny/puppet>
(admin):
>>    centralised configuration management for networks
>>    0.24.5-3: all
>>    - lenny-backports
>> <http://packages.debian.org/lenny-backports/puppet>(admin):
>> centralised configuration management for networks
>>    0.25.4-2~bpo50+1 [*backports* <http://backports.debian.org/>]:
all
>>
>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on
"Thu, 24
>> Jul 2008 10:58:08 +0100". (Days after release, which is good, but
over 2
>> years ago, which is bad..) Looks like 12 releases since then.
>>
>> 0.25.4 was released upstream in January and is -also- not "up to
date"
>> (minor, major, then another minor revs since then..)
> 
> What''s with the nitpicking? They call it "Debian stable"
because it is,
> well, stable. You get what you choose.
> 
> I think the OP suggest that Reductive Labs offer the download of
> packages that both
> a) will install on Debian (stable?) and
> b) offer varying amounts of bleeding-edged-ness.
> 
> This idea is not without merit, I might add.
i know Debian is very stable, but they also have really long release
cycles and sometimes you just want to have the current features.

There is a reason, why many companies are offering her own Debian
packages and i have had many discussions with some of my colleagues,
which are debian developers.

But that is not the point. I need help with my module. ;)

Regards, Dennis

On Wed, Oct 13, 2010 at 8:54 AM, Dennis Hoppe
<dennis.hoppe@debian-solutions.de> wrote:
> Hello Felix,
>
> Am 13.10.2010 16:43, schrieb Felix Frank:
>> On 10/13/2010 04:37 PM, Disconnect wrote:
>>>    - lenny (stable) <http://packages.debian.org/lenny/puppet>
(admin):
>>>    centralised configuration management for networks
>>>    0.24.5-3: all
>>>    - lenny-backports
>>> <http://packages.debian.org/lenny-backports/puppet>(admin):
>>> centralised configuration management for networks
>>>    0.25.4-2~bpo50+1 [*backports*
<http://backports.debian.org/>]: all
>>>
>>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was packaged on
"Thu, 24
>>> Jul 2008 10:58:08 +0100". (Days after release, which is good,
but over 2
>>> years ago, which is bad..) Looks like 12 releases since then.
>>>
>>> 0.25.4 was released upstream in January and is -also- not "up
to date"
>>> (minor, major, then another minor revs since then..)
>>
>> What''s with the nitpicking? They call it "Debian
stable" because it is,
>> well, stable. You get what you choose.
>>
>> I think the OP suggest that Reductive Labs offer the download of
>> packages that both
>> a) will install on Debian (stable?) and
>> b) offer varying amounts of bleeding-edged-ness.
>>
>> This idea is not without merit, I might add.
>
> i know Debian is very stable, but they also have really long release
> cycles and sometimes you just want to have the current features.
>
> There is a reason, why many companies are offering her own Debian
> packages and i have had many discussions with some of my colleagues,
> which are debian developers.
We have an enthusiastic and active Debian packaging group (Hi Stig
Mathias Russ!) and I think we''re managing to balance Debian policy and
user needs pretty well.

If you want the current features, grab the more recent packages. This
is standard Debian practice, and working with distro policy is a good
thing for upstream vendors to do in my opinion.

http://www.debian.org/doc/FAQ/ch-choosing.en.html#s3.1.3

"As you can see, stability and novelty are two opposing ends of the
spectrum. If stability is required: install stable distribution. If
you want to work with the latest packages, then install unstable."

We do need to post up decent instructions on using git-buildpackage to
package your own debs if needed, as it''s a simple couple of commands.
I''ve sent it to this list at least once, but we need to document this
on the puppet deb pkg site.

> But that is not the point. I need help with my module. ;)
Lets get it back on the rails then :)

You might find more luck if you put the manifests into pastebin.com or
directly inline, as it''s much easier for people to glance at your
setup without requiring them to download attachments and unpack them.

-- 
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 Wed, Oct 13, 2010 at 9:01 AM, Nigel Kersten <nigelk@google.com>
wrote:
> On Wed, Oct 13, 2010 at 8:54 AM, Dennis Hoppe
> <dennis.hoppe@debian-solutions.de> wrote:
>> Hello Felix,
>>
>> Am 13.10.2010 16:43, schrieb Felix Frank:
>>> On 10/13/2010 04:37 PM, Disconnect wrote:
>>>>    - lenny (stable)
<http://packages.debian.org/lenny/puppet> (admin):
>>>>    centralised configuration management for networks
>>>>    0.24.5-3: all
>>>>    - lenny-backports
>>>>
<http://packages.debian.org/lenny-backports/puppet>(admin):
>>>> centralised configuration management for networks
>>>>    0.25.4-2~bpo50+1 [*backports*
<http://backports.debian.org/>]: all
>>>>
>>>> Looks pretty out of date to me. Lets see.. 0.24.5-1 was
packaged on "Thu, 24
>>>> Jul 2008 10:58:08 +0100". (Days after release, which is
good, but over 2
>>>> years ago, which is bad..) Looks like 12 releases since then.
>>>>
>>>> 0.25.4 was released upstream in January and is -also- not
"up to date"
>>>> (minor, major, then another minor revs since then..)
>>>
>>> What''s with the nitpicking? They call it "Debian
stable" because it is,
>>> well, stable. You get what you choose.
>>>
>>> I think the OP suggest that Reductive Labs offer the download of
>>> packages that both
>>> a) will install on Debian (stable?) and
>>> b) offer varying amounts of bleeding-edged-ness.
>>>
>>> This idea is not without merit, I might add.
>>
>> i know Debian is very stable, but they also have really long release
>> cycles and sometimes you just want to have the current features.
>>
>> There is a reason, why many companies are offering her own Debian
>> packages and i have had many discussions with some of my colleagues,
>> which are debian developers.
>
> We have an enthusiastic and active Debian packaging group (Hi Stig
> Mathias Russ!) and I think we''re managing to balance Debian policy
and
> user needs pretty well.
>
> If you want the current features, grab the more recent packages. This
> is standard Debian practice, and working with distro policy is a good
> thing for upstream vendors to do in my opinion.
>
> http://www.debian.org/doc/FAQ/ch-choosing.en.html#s3.1.3
>
> "As you can see, stability and novelty are two opposing ends of the
> spectrum. If stability is required: install stable distribution. If
> you want to work with the latest packages, then install unstable."
>
> We do need to post up decent instructions on using git-buildpackage to
> package your own debs if needed, as it''s a simple couple of
commands.
> I''ve sent it to this list at least once, but we need to document
this
> on the puppet deb pkg site.
>
>
>> But that is not the point. I need help with my module. ;)
>
> Lets get it back on the rails then :)
>
> You might find more luck if you put the manifests into pastebin.com or
> directly inline, as it''s much easier for people to glance at your
> setup without requiring them to download attachments and unpack them.
>
I did just unpack all your manifests and it''s hard to work out what
the actual problem is Dennis, as you''ve provided a lot of stuff.

Can you post the actual error messages you''re getting? Is there any
chance you can isolate the problem such that we have a bit less to
trawl through?


-- 
nigel

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

Hello Nigel,

Am 13.10.2010 18:26, schrieb Nigel Kersten:
> ...
> Can you post the actual error messages you''re getting? Is there
any
> chance you can isolate the problem such that we have a bit less to
> trawl through?
actually there is no real error message. It is more about the behavior
of the define, especially the $name variable.

I have a module called "puppet" which is able to handle
"puppetd" and
"puppetmaster" specific configs. It also includes the
"monit" module and
should deploy "/etc/monit/conf.d/puppetmaster" for the host
"rumpel" and
"/etc/monit/conf.d/puppet" for "samson".

node "rumpel" inherits "default" {
	include apticron
	include ldap::slave
	include metche
	include puppet::master
	include rsyslog::master
}

node "samson" inherits "default" {
	include apticron
	include ldap::node
	include metche
	include puppet::node
	include rsyslog::node
}

If i run "puppetd --test --verbose" on host "rumpel" it is
getting the
"monit" configs for "puppetd" and "puppetmaster",
which is intended to
be. But the host "samson" is also getting the config for
"puppetmaster",
which is reproducible.

I think this has something to do with the place or order, where i
include the monit module. Of course i could use the ressource "File[]"
instead of calling the define, but i wanted to learn somthing new and
could not know that it would be so hard to use define over several
modules. ;)

Regards, Dennis

On Wed, Oct 13, 2010 at 07:05:29PM +0200, Dennis Hoppe
wrote:
> 
> node "rumpel" inherits "default" {
> 	include apticron
> 	include ldap::slave
> 	include metche
> 	include puppet::master
> 	include rsyslog::master
> }
> 
> node "samson" inherits "default" {
> 	include apticron
> 	include ldap::node
> 	include metche
> 	include puppet::node
> 	include rsyslog::node
> }
> 
> If i run "puppetd --test --verbose" on host "rumpel" it
is getting the
> "monit" configs for "puppetd" and
"puppetmaster", which is intended to
> be. But the host "samson" is also getting the config for
"puppetmaster",
> which is reproducible.
This is almost certainly because of where you have included the monit
class, which is not visible in the modules you have attached here.   I
could speculate about that, but I don''t know how you''ve
written the rest
of your manifests.

One thing, though: you have a huge amount of duplicated code there;
it''s
more work than you need to do and a potential source of error.  Your
lenny and squeeze monit classes, for example, are almost identical; it
would make much more sense to have one class and use selectors ("if",
"case" etc.) for the minor bits which are different.  As things stand,
if you change the structure of your monit module, you''ll have to make
changes twice: once in the lenny version, once in the squeeze version.
You have so many duplicate classes that you''re bound to slip somewhere
and make the change in one version and not in the other (or do it
slightly differently in the other).  That kind of thing can be very
difficult to trace.

-- 
Bruce

What would Edward Woodward do?

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

Hello Bruce,

Am 13.10.2010 19:36, schrieb Bruce Richardson:
> On Wed, Oct 13, 2010 at 07:05:29PM +0200, Dennis Hoppe wrote:
>>
>> node "rumpel" inherits "default" {
>> 	include apticron
>> 	include ldap::slave
>> 	include metche
>> 	include puppet::master
>> 	include rsyslog::master
>> }
>>
>> node "samson" inherits "default" {
>> 	include apticron
>> 	include ldap::node
>> 	include metche
>> 	include puppet::node
>> 	include rsyslog::node
>> }
>>
>> If i run "puppetd --test --verbose" on host
"rumpel" it is getting the
>> "monit" configs for "puppetd" and
"puppetmaster", which is intended to
>> be. But the host "samson" is also getting the config for
"puppetmaster",
>> which is reproducible.
> 
> This is almost certainly because of where you have included the monit
> class, which is not visible in the modules you have attached here.   I
> could speculate about that, but I don''t know how you''ve
written the rest
> of your manifests.
maybe you are right. If i use something like that, my problem seems to
be solved. Because in this case i am making a node specific declaration,
which i have to made for all my nodes and services. But i was looking
for some kind of automatism, because the "monit" module should come
with
certain modules, which are choosing the right "monit" config.

node "rumpel" inherits "default" {
   include apticron
   include ldap::slave
   include metche
   include monit
   monit::lenny::config { "puppet": }
   monit::lenny::config { "puppetmaster": }
   monit::lenny::config { "rsyslog": }
   monit::lenny::config { "ssh": }
   include puppet::master
   include rsyslog::master
}
> One thing, though: you have a huge amount of duplicated code there;
it''s
> more work than you need to do and a potential source of error.  Your
> lenny and squeeze monit classes, for example, are almost identical; it
> would make much more sense to have one class and use selectors
("if",
> "case" etc.) for the minor bits which are different.  As things
stand,
> if you change the structure of your monit module, you''ll have to
make
> changes twice: once in the lenny version, once in the squeeze version.
> You have so many duplicate classes that you''re bound to slip
somewhere
> and make the change in one version and not in the other (or do it
> slightly differently in the other).  That kind of thing can be very
> difficult to trace.
Right, some other people at this mailing list already gave me that
advice. I know that i have a lot of duplicated code, but i thought this
would be easier to maintain, if a release is getting end of live status.

Anyway, i am experiencing the first trouble with the way how i choose
the releases and should think about a redesign of my puppet modules.
Fortunately i am just at the beginning. ;)

Regards, Dennis

On Wed, Oct 13, 2010 at 09:20:18PM +0200, Dennis Hoppe
wrote:
> > This is almost certainly because of where you have included the monit
> > class, which is not visible in the modules you have attached here.   I
> > could speculate about that, but I don''t know how
you''ve written the rest
> > of your manifests.
> 
> maybe you are right. If i use something like that, my problem seems to
> be solved. Because in this case i am making a node specific declaration,
> which i have to made for all my nodes and services. But i was looking
> for some kind of automatism, because the "monit" module should
come with
> certain modules, which are choosing the right "monit" config.
> 
> node "rumpel" inherits "default" {
>    include apticron
>    include ldap::slave
>    include metche
>    include monit
>    monit::lenny::config { "puppet": }
>    monit::lenny::config { "puppetmaster": }
>    monit::lenny::config { "rsyslog": }
>    monit::lenny::config { "ssh": }
>    include puppet::master
>    include rsyslog::master
> }
What a lot of us do is create classes that describe a particular role
(like "role::storage_server") and put all the smaller classes and
specialized behaviour in that.  Then you include the "role" class in
the
node and declare any variables that need to be set (or overridden from
their defaults) in the node as well.  That keeps the node definition
tidy but also means, since all classes are included at the individual
node level, that the classes pick up the variable values specific to
them.

So I might define a site::role::basic_server class which included monit
and apticron.  Then I''d define site::role::puppetmaster, make that
either inherit from or include site::role::basic_server (whichever is
most appropriate), have it define monit::config { "puppetmaster" } and
include puppet::master (and so on).  Then I''d have the rumpel node
include site::role::puppetmaster.

The benefits I get from this are a) the ability to assign the same role
to multiple nodes (or to reassign the role from one node to another)
simply and clearly, b) to be sure that the value of any important
variable can be overridden for any one node, c) ... oh, there are other
benefits but those two are good.

I''m not saying that you shouldn''t include more than one class
in a node,
particularly if you have specialist classes which aren''t often used,
but
roles are very helpful, especially where you want to establish
particular dependencies between particular modules or classes.
> > You have so many duplicate classes that you''re bound to slip
somewhere
> > and make the change in one version and not in the other (or do it
> > slightly differently in the other).  That kind of thing can be very
> > difficult to trace.
> 
> Right, some other people at this mailing list already gave me that
> advice. I know that i have a lot of duplicated code, but i thought this
> would be easier to maintain, if a release is getting end of live status.
Which Debian release you are using is really a minor detail; the intent
behind (for example) a monit module remains the same.  In fact, in the
two modules you have included, your twinned lenny/squeeze classes are
*identical* apart from the class names themselves.  Even the templates
are identical.  You are wasting a lot of time duplicating things that
are the same.  I''m a litle confused to see no package dependencies in
those modules - really, a module should be a self-contained unit that
contains everything that describes the core function.  Even if you
decide you want a special package-handling module (which can look
attractive when you first come to Puppet but really is normally not
worth it), you should be realizing those packages in the relevant
module.

-- 
Bruce

It is impolite to tell a man who is carrying you on his shoulders that
his head smells.

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

Hello Bruce,

Am 13.10.2010 23:14, schrieb Bruce Richardson:
> On Wed, Oct 13, 2010 at 09:20:18PM +0200, Dennis Hoppe wrote:
>>> This is almost certainly because of where you have included the
monit
>>> class, which is not visible in the modules you have attached here. 
I
>>> could speculate about that, but I don''t know how
you''ve written the rest
>>> of your manifests.
>>
>> maybe you are right. If i use something like that, my problem seems to
>> be solved. Because in this case i am making a node specific
declaration,
>> which i have to made for all my nodes and services. But i was looking
>> for some kind of automatism, because the "monit" module
should come with
>> certain modules, which are choosing the right "monit" config.
>>
>> node "rumpel" inherits "default" {
>>    include apticron
>>    include ldap::slave
>>    include metche
>>    include monit
>>    monit::lenny::config { "puppet": }
>>    monit::lenny::config { "puppetmaster": }
>>    monit::lenny::config { "rsyslog": }
>>    monit::lenny::config { "ssh": }
>>    include puppet::master
>>    include rsyslog::master
>> }
> 
> What a lot of us do is create classes that describe a particular role
> (like "role::storage_server") and put all the smaller classes and
> specialized behaviour in that.  Then you include the "role" class
in the
> node and declare any variables that need to be set (or overridden from
> their defaults) in the node as well.  That keeps the node definition
> tidy but also means, since all classes are included at the individual
> node level, that the classes pick up the variable values specific to
> them.
> 
> So I might define a site::role::basic_server class which included monit
> and apticron.  Then I''d define site::role::puppetmaster, make that
> either inherit from or include site::role::basic_server (whichever is
> most appropriate), have it define monit::config { "puppetmaster"
} and
> include puppet::master (and so on).  Then I''d have the rumpel node
> include site::role::puppetmaster.
> 
> The benefits I get from this are a) the ability to assign the same role
> to multiple nodes (or to reassign the role from one node to another)
> simply and clearly, b) to be sure that the value of any important
> variable can be overridden for any one node, c) ... oh, there are other
> benefits but those two are good.
> 
> I''m not saying that you shouldn''t include more than one
class in a node,
> particularly if you have specialist classes which aren''t often
used, but
> roles are very helpful, especially where you want to establish
> particular dependencies between particular modules or classes.
> 
>>> You have so many duplicate classes that you''re bound to
slip somewhere
>>> and make the change in one version and not in the other (or do it
>>> slightly differently in the other).  That kind of thing can be very
>>> difficult to trace.
>>
>> Right, some other people at this mailing list already gave me that
>> advice. I know that i have a lot of duplicated code, but i thought this
>> would be easier to maintain, if a release is getting end of live
status.
> 
> Which Debian release you are using is really a minor detail; the intent
> behind (for example) a monit module remains the same.  In fact, in the
> two modules you have included, your twinned lenny/squeeze classes are
> *identical* apart from the class names themselves.  Even the templates
> are identical.  You are wasting a lot of time duplicating things that
> are the same.  I''m a litle confused to see no package dependencies
in
> those modules - really, a module should be a self-contained unit that
> contains everything that describes the core function.  Even if you
> decide you want a special package-handling module (which can look
> attractive when you first come to Puppet but really is normally not
> worth it), you should be realizing those packages in the relevant
> module.
thank you for your detailed answer. I have not thougt about roles
before, but it really makes sense. I also reviewed my modules and took
notice that this massive use of release declaration has to end. ;)

Regards, Dennis

Hello Nigel,

Am 13.10.2010 17:35, schrieb Nigel Kersten:
> ...
> Have you tried running the recent packages on Debian stable? They do
> work, you''re more than welcome to go to a bleeding edge release if
you
> wish.
> 
> This is all pretty standard practice for Debian...
> 
> I wasn''t being sarcastic. I was pointing out the more recent
packages
> you''re welcome to try.
today i used "pbuilder" to make an backport of the current
"puppet"
packages. Did not thought that it would be so easy. ;)

Regards, Dennis