[Puppet Users] Re: Negate or uninclude a class

jcbollinger
Mon, 18 Oct 2010 14:20:10 -0000

On Oct 18, 4:38 am, Bruce Richardson <itsbr...@workshy.org>
wrote:
> No, you can''t uninclude a class.

Right.

> > Is the only way to do this to inherit the base class and override all
> > it''s resources to do the equivalent of "ensure =>
absent", then
> > something like "if (tagged(class)) { include undo-subclass }
" where
> > needed?

[...]

> You *could* do it with overrides but only If you were using a define
> within your base class for part of the setup and that define took a
> parameter which told it whether to include the ldap class.

You could write it that way, but Puppet''s subclassing feature is
designed precisely so that you don''t need to do so.  It goes something
like this:


class ldap::client {
    # whatever resources are needed, such as ...
    file { "some-config-file":
        source => "normal-source"
    }
}

class ldap::client::disabled inherits ldap::client {
    # Override parent class resources as appropriate,
    # for example ...
    File["some-config-file"] { source =>
"alternative-source" }
}

node default {
    include "ldap::client"
}

node "my-ldap-server" inherits default {
    include "ldap::client::disabled"
}


It does not matter that node "my-ldap-server" inherits node
"default",
so that "my-ldap-server" directly or indirectly includes both
"ldap::client" and "ldap::client::disabled".  If a subclass
overrides
a property of a superclass''s resource, then it''s as if that
property
were changed *in the parent class* for nodes that include the
subclass, and there is no conflict if a node includes both classes.
That is perfectly suited to the situation here, and it also serves
well in the event that class "ldap::client" may be included not just
by nodes but also by other classes.  Where you do not leverage those
properties, you should not use subclasses.  In a case such as the one
we''re discussing here, however, subclasses can be a big win.

For example, although Bruce''s main suggestion could be used if for
some reason it were important to avoid subclasses, really in that case
something akin to his define-based suggestion (but without subclasses)
would be better.  That way, if the LDAP client somehow gets turned on
on your LDAP server, then Puppet will turn it back off.  Unconfigured
means "I don''t care"; it must not be confused with
"off".  The
subclass usage pattern above achieves the same thing with no
conditional inclusions and no define, plus it''s safe against inclusion
of "ldap::client" by other parts of the manifest.


Best,

John