Puppet users - May 2011 - Disable class by exception (not disable service in a class)

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. I''m
looking to have an most encompassing default node class and by
exception provide overrides by ENC''s with dashboard. Whilst
I''m fine
with the concept of adding a class to a node in dashboard to use, for
example, sshd::disabled, but what if I want to just remove all trace
of the class, so a very simple example is a class I''ve written to
manage /etc/hosts. So it just sticks a templated file there, nothing
worth pasting, but how do I, by exception, ignore the file totally?

I''ve seen a few interesting things using variables in the class name
(e.g. "include foo::$operatingsystem") (from here -
http://m0dlx.com/blog/Puppet_manifests__a_multi_OS_style_guide.html )
and I can see how that variable (not that one obviously, but something
new) could be used to include an empty class instead, but this feels
hacky for the way I would think I could use it here - not least
because I''d have to call "include foo::enable" or such like
for every
module, which can''t be good style. My initial thought would be to put
a conditional to bypass a resource, but again assume that''s pretty
ugly too.

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.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
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 5 May 2011 14:04, jcbollinger <John.Bollinger@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

}

==========
So under puppet dashboard I can create a variable  called
"exclude_classes"
and give it in array of class names, and while iterating through a list of
defaults, if the candidate class is in the exclude_classes list it
won''t be
included.

Any thoughts / style tips would be very much appreciated, as this still
feels wrong, but I''d love it if it wasn''t! Is it good to have
a baseclass
there when that code could all be direct within the default node?

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> 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: }
> 
> }
Sort of funky, I like it!

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 ;-)

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.

On Thu, May 5, 2011 at 9:14 AM, Chris Phillips <chris@untrepid.com>
wrote:
>
>
> On 5 May 2011 14:04, jcbollinger <John.Bollinger@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

-- 
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 5 May 2011 14:52, Felix Frank <felix.frank@alumni.tu-berlin.de>
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 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 5 May 2011 17:22, Nan Liu <nan@puppetlabs.com> wrote:
> On Thu, May 5, 2011 at 9:14 AM, Chris Phillips <chris@untrepid.com>
wrote:
> >
> >
> > On 5 May 2011 14:04, jcbollinger <John.Bollinger@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>     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.
Consider this code (which works - I''ll be damned):

class a { notify { "a included": } }
class b { notify { "b included": } }
class c { notify { "c included": } }

class include_it {
        define includer($exclude=false) {
                if !$exclude {
                        include $name
                }
        }

        includer { [ "a", "b", "c" ]: }

        class no_a inherits include_it {
                Includer["a"] { exclude => true }
        }

        class no_b inherits include_it {
                Includer["b"] { exclude => true }
        }

        class no_c inherits include_it {
                Includer["c"] { exclude => true }
        }
}

include include_it
include include_it::no_a
include include_it::no_c

In order to get rid of any include, you include the respective
excluder-subclass in your node (using Dashboard or whatever).

Question to the community: Pattern or anti-pattern? :-)

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