[Puppet Users] Re: Negate or uninclude a class

jcbollinger
Wed, 20 Oct 2010 16:57:30 -0000

On Oct 19, 6:04 pm, Bruce Richardson <itsbr...@workshy.org>
wrote:
> [...] I agree with you about the
> importance of state, but in that scenario, to me, not being an LDAP
> client is the basic state.

After much consideration, I think a great deal of this debate hinges
on that definition.  It is perfectly reasonable, but not exclusively
so.  For instance, my basic state is for systems to be NIS clients.
It seems most reasonable to me for the basic state to provide those
configuration details from which few of my systems deviate.  The OP''s,
at present, is for systems to be LDAP clients.

> The basic, clean state of a system should be
> something Puppet protects from the start; including classes should
> modify or extend that and, in most cases, I expect my configuration to
> be protective enough of the core and well known functionality so that
> it should make no difference whether a class was previously included and
> then dropped or never included in the first place.

I don''t quite understand that.  How does your configuration protect
the basic state of a system without including classes?  You could use
global resources, but then those could not be overridden.  I suspect
that instead you have one or more core classes that you include on
every node to establish and maintain the basic state; that seems
consistent with your further comments.  Particular nodes then include
*other* classes to modify or extend.

[...]

> I certainly know enough about the core components of a
> system (nsswitch, pam, fstab and so on), to know what will interfere
> with that and what is irrelevant.  The seed of any configuration, for
> me, would be locking those down in their simple and functional state.
> This means that including an ldap::client will extend that, but in the
> absence of ldap::client, the core function will be restored.

I think you''re saying that you would implement ldap::client itself
using subclassing if (and only if) it needs to alter anything in the
core.  There''s merit to that, and doing it that way could indeed have
exactly the results you describe.  No further subclass would be
required.

But how does this apply to the OP?  His current basic state is for
systems to be LDAP clients.  That''s not what you would choose, but if
he retains that choice, then does not your approach call for
subclassing where a node must not be an LDAP client?  Such nodes would
then include ldap::client::disabled to override the base, and dropping
that class would restore base functionality, just as you recommend.
In all likelihood, such a subclass could be very slim: it probably
needs to override only a small number of resources to disable the
client (maybe just /etc/nsswitch.conf); it shouldn''t need to
completely counter everything in ldap::client.

> I do
> not share your nervousness about purging - purge and well managed
> resources - and judicious use of virtual ones - is generally cleaner
> than a whole set of twinned active/inactive classes.  It doesn''t
mean I
> never, ever write a disable/cleanup class but it isn''t my habit.

I''m curious: what types of resources do you purge, in what contexts?
Your configuration philosophy seems similar to mine in that you don''t
try to manage every system detail, but that rather limits the
available scope for purging, doesn''t it?

[...]

> This is more than semantic quibbling about how to label different
> states; inheriting and overriding a more complex state to impose a
> simpler state is not the same as defaulting to the simpler state.

Much then depends on the chosen measure of complexity.  I think you
mean to judge by some measure of distance between the target state and
a base reference state, which I take to be your "basic" /
"clean"
state.  Your recommendations then make good sense when you stipulate
the existance of a default state to fall back on, especially when
coupled with purging to clean up potentially troublesome unwanted
resources (thanks for those clarifications).

How that applies to the OP''s case is a different question, however.
If he continues to rely on a base state in which the LDAP client is
enabled, then overriding that state to disable the client leads to a
more complex state (by the above standard).  As I said at the
beginning, much seems to hinge on the choice of base state.


Our positions now seem much closer than they originally did.  I won''t
argue over how a system''s base state should be constituted --
that''s
too subjective -- and otherwise we seem largely to agree.  Overall, my
main objection to your original response was about your claim that a
subclass-based solution would require use of defines and
conditionals.  You seem to have backed off on that, so I think we''re
good.


Cheers,
John