On Jul 13, 11:39 am, Darrell Fuhriman <darr...@garnix.org> wrote:
> I've always thought there should be an implicit X::disabled class that gets
> included for every host where X isn't included.
>
> Then if I create said class, it gets automatically executed on all hosts that
> don't include X.
It is not practical to do this even at resource level, because for
many resources it is unclear what the opposite resource would be.
Exec resources are the canonical example ("don't run" is not at all
the same thing as "reverse the changes produced by running"). There
are in fact issues with most, if not all, resource types because
Puppet does not keep track of the state before applying a resource.
Even if Puppet *did* track prior state, there would still be an issue
of choosing which of possibly many prior states to revert to.
To do this at class level is worse, because in addition to not knowing
how to reverse a class's resources, it is very difficult in the
general case to determine even which resources would need to be
reversed. Conditional statements, selectors, variables, virtual and
exported resources, and class parameters are some of the many things
that complicate the analysis.
And even if all the above could somehow be satisfactorily resolved,
there remains the problem that the concept is fundamentally flawed.
Declining to include a class simply cannot reliably be interpreted as
an intention to "unmanage" the resources managed by that class. As
just one example, consider classes that are omitted because they are
inapplicable to the node in question: maybe they are for a different
OS than the node's, or maybe they are one of a series of alternative
classes.
Furthermore, that analysis ignores the question of whether the
behavior described would be desirable even if it were possible. It
would not be for me, as it would make writing classes a lot more
difficult. I would have to be careful to write each class so that the
automatic opposite would also work, and I am confident that that would
not be trivial.
> As it is now, one still has to go through and add X::disabled to every host,
> which is largely defeating the purpose of having a X::disabled class in the
> first place. (That purpose, for those not paying attention, is to make sure
> that things are in a known state, including services *not* running where they
> shouldn't be.)
I disagree. The purpose of having an X::disabled is to define what
exactly you do want when you explicitly want to exclude X. Which
nodes should have that state ensured is an entirely separate (and not
clear-cut) question. "Unmanaged" may not be the state you want for
certain resources, but it is not inherently undesirable for all
resources.
It is yet another separate question how to achieve the correct casses
being included on each node. For example, if you want X to be
disabled on every node where it is not enabled, then one alternative
is to invert the class inheritence: class X defines the *disabled*
state of X, and is included in a default node definition inherited by
all other node definitions. Then a class X::enabled subclasses X and
overrides resources as necessary to establish the "enabled" state;
nodes that want X enabled include X::enabled. That avoids explicitly
including a specific X class in every node declaration.
Alternatively, the issue is easily addressed if you use an external
node classifier. Or you can indeed put one of X and X::(enabled|
disabled) in every node declaration if that is indeed what you want to
do. Some would prefer the explicitness of that style.
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
