On 5 May 2011 17:22, Nan Liu <n...@puppetlabs.com> wrote:
> On Thu, May 5, 2011 at 9:14 AM, Chris Phillips <ch...@untrepid.com> wrote:
> >
> >
> > On 5 May 2011 14:04, jcbollinger <john.bollin...@stjude.org> wrote:
> >>
> >>
> >> On May 3, 3:56 pm, Chris Phillips <ch...@untrepid.com> wrote:
> >> > Hi,
> >> >
> >> > I don't know if I'm just not getting it, but I'm struggling to find
> >> > "the" way to elegantly disable a class in its entirety. I am aware of
> >> > the foo::disabled conventions, but these are about the disabling of
> >> > the end service defined by the class, not the class itself.
> >>
> >>
> >> [...]
> >>
> >>
> >> > So again, I just want to wipe out the impact of the class, unmanage as
> >> > it were, replace the contents with a nice simple { } regardless of
> >> > what it was written to do maybe, not force disabling of the end
> >> > result, and I'm assuming there is a great and painfully simple way to
> >> > do this with style, but it's missing me right now.
> >>
> >>
> >> There is no way to achieve precisely what you ask. Instead, you must
> >> avoid including the class in the node's catalog in the first place.
> >> Use conditional statements in your manifests (if / case) to select
> >> based on nodes' facts whether to include it, or include it only for
> >> certain nodes (which amounts to the same thing).
> >>
> >> From the perspective of designing an ENC, you should be looking to add
> >> classes to a common base rather than subtract classes from an omnibus
> >> configuration. For what it's worth, I think that would still be a
> >> better design paradigm even if Puppet could provide the alternative.
> >>
> >>
> >> John
> >
> >
> > Thanks John, appreciated. Whilst I totally see the logic in adding to a
> > base, if 99% of machines want all these classes, and only a
> > real exception would this be deviated from (indeed I currently have no
> > deviations, but don't want to be caught by it when it's sure to come
> along)
> > the base is going to be irrelevant if some of the "99%" modules aren't in
> > it.
> > I've come up with this methodology which seems to technically work...
> > ===========
> > class baseclass {
> > $classes = ["aaa", "access", "banner", "func", "hosts", "munin",
> "ntp",
> > "resolv", "rhn", "rsyslog", "ssh", "sudo"]
> > define include_class() {
> > if ($exclude_classes == undef) or ! ($name in $exclude_classes) {
> > include $name
> > }
> > }
> > include_class{ $classes: }
> > }
> > node default {
> > include baseclass
> > }
>
> Do not follow by my bad example of abusing inline_templates (write a
> puppet function instead), but this should work for your use case:
>
> $class = inline_template("<% [classes].flatten - [exclude_classes].flatten
> %>")
> class { [$class]: }
>
> Thanks,
>
> Nan
Ahh, that's nice. I was looking for intersections and things, but not
knowing ruby originally I'm still really unsure how the puppet and template
codes relate to what's possible in ruby. Seems just as confusing as
interlinking python and cheetah in cobbler. Not dared to write a function
yet, but may well be worthwhile having a look.
What is the need for the flatten? Is that just for completeness, as I'm not
planning on dealing with multi-dimensional arrays at all. I can certainly
imagine it might be best practices etc. Could this relate to dealing with a
possibly non-existent exclude_classes variable?
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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
