>
> That still isn't sensible. It simply is not safe to assume that the
> absence of class X in a node's catalog is a signal that X::disabled
> should be included in that catalog. For instance, suppose I have a
> pair X, X::disabled of classes specific to OS X. I don't want *either
> one* on my CentOS boxes.
Fair enough. I habitually write classes with something like:
class foo {
case $operatingsystem {
default: { fail ("X is not implemented for $operatingsystem") }
centos {[...]}
darwin: {[...]}
}
[....]
}
So your scenario wouldn't affect me anyway. But I'm anal-rententive that way. I
can't imagine why you *wouldn't* do that if you're going to be running on more
than one platform.
I actually wish puppet had a 'confine' parameter for classes like it does for
custom facts. It would make it easier to avoid shooting yourself in the foot.
class foo {
confine $kernel => ['Linux', 'Darwin']
}
Anyway, it's a problem, yes, but not an insurmountable one.
> Consider also what happens when X, Y, X::disabled, and Y::disabled all
> exist, and Y::disabled includes X. Suppose that after Puppet's initial
> pass to choose which classes to include, it sees that neither X nor Y
> is included, so it adds X::disabled and Y::disabled. But Y::disabled
> includes X, so X::disabled shouldn't be included after all! Or should
> it?
Well, in that situation the right answer would be that only X is included. How
much work that is to implement in the current puppet parser, I have no idea.
But that's irrelevant to the question at hand.
Plus, why the hell would anyone want to do that? If you put includes into your
!X classes, you've clearly failed to understand the concept and should be taken
far away from any keyboards and put into a systems administration re-education
camp. I'd go so far as to say that any !X class could not include another class
at all. (And obviously !X classes could not be included explicitly anywhere,
since that's also fundamentally missing the point.)
>
>> Maybe we have different approaches to how we manage resources, but I
>> genuinely can't think of an example of where you would want some hosts to be
>> X, some to be !X, and some to be unknown, which is kind of what I think
>> you're saying here, because I can't think of anyway that "unmanaged" doesn't
>> mean "unknown".
>
>
> [...] Dev and test boxes present a wide
> variety of examples where looser management of some resources may be
> desired than for production boxes.
*shudder* Down that path lies madness, if you ask me. To my mind, either
something's managed or it isn't – there is no alternative that doesn't end in
tears. But again, these things are easily solved by saying something like:
class !foo {
case $environment {
default: { #do nothing }
production: { # do stuff }
}
}
Because then at least you're forced to be explicit about what your management
policy is, even if that policy is "we let dev machines do whatever they want to
service foo".
But that's because I want the puppet configs to be the first (and ideally only)
place I need to go to find out what a given system's state is. That's why I
automate in the first place. It's also the basis for my wanting a !X class –
because currently I have no easy way of knowing if node Y is running a
webserver or not without logging into it and checking. If I had a !webserver
class, I could feel confident that node Y is not a webserver just by looking at
the puppet configs.
That's good for security, good for auditing, good for performance, and good for
piece of mind. :)
Darrell
--
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.
