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
signature.asc
Description: OpenPGP digital signature
