On Tue, Oct 19, 2010 at 09:00:16AM -0700, jcbollinger wrote:
> The subclass approach definitely does not override the superclass to
> do nothing. Much to the contrary, it overrides the superclass so that
> together (whether the superclass is directly included or not) they
> ensure the correct configuration for a system that is not, in the
> example, an LDAP client. In other words, the servers are configured
> as non-clients, rather than leaving their client status unmanaged.
> There will be file differences between clients and non-clients, and
> possibly differences in such things as installed packages and service
> configuration. It is wise to manage those differences, whether
> whether via subclassing or otherwise.
That's topsy turvy, in my opinion. I agree with you about the
importance of state, but in that scenario, to me, not being an LDAP
client is the basic state. 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.
Here's my rationale: most of us do not have the luxury of knowing
everything about every aspect of every package that may be installed on
a typical Linux/*nix system (unless you're the chief architect at Red
Hat/SuSE or wherever, in which case you may have a shot). That isn't a
terrible problem; we can know enough about the core to be aware of what
is significant. 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. There are
cases where the past inclusion of a class will litter a system with
packages and configuration that do interfere, but those are rare. 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.
It's a defensive approach but, given that I'm not Red Hat's chief
architect, lack the time to weigh every package in the balance but do
have responsibility for relatively up to date Red Hat and Centos systems
(Debian too, but that's a slower moving target), it seems to me both
saner and less work than adding disable classes to everything. It's
also less work and the code is cleaner, so I'd probably do it even if I
were the very source of all knowledge of RHEL's eccentricities.
My basic samba class configures a minimal smb.conf to be aware of the local
workgroup/domain but have no shares and explicitly disables all
samba-related services. samba::member, samba::pdc and others inherit
and extend. No longer including them undoes the damage, so to speak.
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.
So in my situation, "if <condition> { include class }" works very well.
--
Bruce
Explota!: miles de lemmings no pueden estar equivocados.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
