On Jul 14, 12:16 pm, Darrell Fuhriman <darr...@garnix.org> wrote:
> > 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.
>
> I'm not asking puppet to know what to do, which I agree is ridiculous. I'm
> saying that if and only if I've defined X::disabled, automatically run it on
> every host which does not include X. If X::disabled isn't defined, then don't
> do anything. Probably a better way to think of it instead of X::disabled is
> that for ever class X there is an implicitly defined not-X class, which is
> empty until I define it. For example:
>
> class webserver {
> package {apache: ensure => installed}
> service {apache: ensure => running}}
>
> class !webserver {
> package {apache: ensure => absent}}
>
> class dnsserver {
> [...]
>
> }
>
> node "foo" {
> include webserver}
>
> node "bar" {
> include dnsserver
>
> }
>
> On node bar, !webserver would get executed, but because I haven't defined
> !dnsserver, node foo wouldn't do anything related to dnsserver.
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.
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?
> >> 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.
>
> I'm not sure I understand what you're saying here. It is perfectly reasonable
> to want to ensure that things which aren't webservers are, in fact, not
> running as webservers,
No argument there.
> If I want to leave a particular resource unmanaged, then just don't put
> anything in the !X class (or the X class, for that matter).
Fair enough. Your clarification of how you imagined the feature
working clears up that bit.
> 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".
Classes specific to a particular OS are such an example with respect
to nodes running a different OS. Dev and test boxes present a wide
variety of examples where looser management of some resources may be
desired than for production boxes.
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.
