On Friday, July 5, 2013 12:20:55 PM UTC-5, francois.l...@gmail.com wrote:
>
>
>
>>
>> The recommended way
>> forward is to express the configuration dependency explicitly like so:
>>
>> class meta($one = true) {
>> if $one {
>> include one
>> }
>> or to directly integrate this into the class two. This depends on your
>> actual use case.
>>
>
> Sorry, but I tried to understand your example but I didn't. Do I have to
> put the "meta" class in the yaml file of my host? If yes, I don't see why
> it solves the problem. Sorry. I'm a puppet beginner.
>
David inferred, as do I, that your intention is for class 'two' to make
different declarations when class 'one' is also declared for the target
node than when it is not. His idea was to use a separate class to manage
the parse-time dependencies between class 'two' and class 'one'. David was
suggesting that instead of declaring those classes directly, you declare
only class 'meta', letting it take care of declaring the others (or not).
A parameter of that class controls whether class 'one' is declared, and its
value is forwarded to class 'two' (as a new parameter) to tell that class
whether class 'one' is declared.
The YAML is a secondary issue. In fact, I'm surprised that you're doing
anything with YAML at such an early stage in your testing. I suppose you
are trying to use an external node classifier (ENC), but it might be better
to start out with ordinary node declarations in site.pp until you get a
better handle on how Puppet works.
>
> In fact, I'll explain the purpose of my post. I have choose a simplied
> example.
> I have a class named "monitoring" (but in my example it's the "two" class)
> in which I want to define some variables according to some other classes
> are used or not by the host. I show you :
>
> class monitoring {
>
> # if the host uses the http class $http = "http" else $http = "NONE"
>
> # if the host uses the mysql class $mysql = "mysql" else $mysql = "NONE"
>
> # etc.
> }
>
> I thought tagged() function will make the job but, as you explain me, it's
> order-dependent. I'll try to think about your example...
>
>
There is a key difference between that and your original example, which
makes a lot of difference: your 'monitoring' class has dependencies on a
bunch of different classes, rather than on only one. You could still
construct a solution along the lines of David's suggestion, but under these
circumstances I would suggest a different approach.
First, split up your 'monitoring' class into several separate classes: one
for the modeling framework and your general modeling requirements, and a
separate class for each service you want to be able to monitor (e.g.
monitoring::httpd, monitoring::mysql, etc.). Perhaps you already have such
a division. Have each of the service-specific monitoring classes declare
the main monitoring class; e.g.
class monitoring::httpd {
include 'monitoring'
# ...
}
Next, declare the service-specific monitoring classes explicitly. If
you're doing it via an ENC, then it would look like this:
classes:
- httpd
- monitoring::httpd
- mysql
- monitoring::mysql
That has the added advantage that you can pick and choose which services
are monitored.
If you want to reduce the number of separate classes declared then you can
combine that with something along the lines of David's suggestion. There
are several ways to do that, but I think I'd do it like this:
class site::httpd_monitored {
include 'httpd'
include 'monitoring::httpd'
}
class site::mysql_monitored {
include 'mysql'
include 'monitoring::mysql'
}
classes:
- site::httpd_monitored
- site::mysql_monitored
That reduces the number of classes to one per service, retains the ability
to pick and choose what is monitored, and avoids introducing any direct
dependency between the service modules (httpd and mysql) and the monitoring
module.
John
--
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+unsubscr...@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.
For more options, visit https://groups.google.com/groups/opt_out.
