On 5 May 2011 14:52, Felix Frank <[email protected]> wrote:
>
>
> Sort of funky, I like it!
First and last time for everything!
It may work, but $exclude_classes should not be a vairable, but a
> parameter to your define instead.
>
> This way, you can override the include_class in a subclass of baseclass
> to set exclude_class to the name of the class.
>
> You can have it easier by making this a boolean:
>
> baseclass {
> define include_class($exclude = false) {
> if !$exclude { include $name }
> }
> }
>
> class baseclass::no_rsyslog {
> Include_class["rsyslog"] { exclude => true }
> }
>
> Let me know if this works, because it would rule ;-)
I don't really understand the usage here. One key thing I want to do is to
be able to do all customization within dashboard, and never need to go back
to manifests for per system personalization. As I understand this take on
it, I would need to override the baseclass in a different way for every
permutation that I want to use? baseclass::no_rsyslog_or_func_or_aaa?
Whilst I would probably feel more comfortable configuring classes as
classes, not arbitrary strings which are used as classes later, I don't see
a way to have the flexibility I'd really like any other way. I'm *very* new
to this "next level" of puppet though, and picking up things so fast I seem
to spend most of my time replacing the previous thing I did that morning.
Does the association of these overridden classes via an external node
replace the inclusion of the original baseclass in the default node? I would
expect both to be included in parallel, meaning, in this example, rsyslog
would be included and excluded seperately, so still ultimately be included.
Thanks
Chris
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
