On Jul 14, 6:48 pm, Darrell Fuhriman <darr...@garnix.org> wrote:
[...]
> 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.
It's fine to *wish* for a feature that would make your life easier,
but it is unreasonable to expect such a feature to be implemented when
it carries with it serious technical and practical problems for people
who build their manifests differently than you do. Puppet needs to do
a good job handling everything its DSL can express, explicitly or
implicitly, which is one reason why its semantics do not include
implicitly adding classes to catalogs, and probably never will.
> 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']
> }
I wouldn't have a problem with that, but you can accomplish the same
thing now with a conditional around the whole class body.
> Anyway, it's a problem, yes, but not an insurmountable one.
It depends on what you mean by 'insurmountable'. If the DSL suffered
from that problem then yes, users could avoid it by taking care to use
certain coding techniques, but that just treats the symptom. The
underlying problem is that the DSL would contain additional traps for
unwary and inexperienced users, and it would be capable of expressing
undecidable declarations. Moreover, adding the feature at this point
would require everybody to audit all their manifests for compatibility
with this behavior change. People are fallible, so some breakage
*would* occur.
> > 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.
Perhaps, but but what if also X::disbled includes Y? Then it is
completely undeterminable which classes to include. Real-life
manifests are unlikely to have such a tight mutually-contradictory
loop, but they might easily have one involving a longer chain.
> 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?
Why do you suppose they wouldn't? It's entirely likely that
foo::disabled classes would often want to include other classes. For
instance, if foo::disabled ensures Service['foo'] stopped, then it
must also ensure that Package['foo-service'] is installed, which is
accomplished by some other class in a sufficiently DRY manifest set.
Or if it ensures a different state of some configuration file than
does class foo, then it may need to manage the directory in which that
file lives, which again is likely to be in some other class. Since it
is likely that foo::disabled classes will include other classes, it is
unreasonable to assume that cycles would never occur.
> 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.)
I don't think you've thought this all the way through.
> >> 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".
Your overall theme seems to be "there are ways to write manifests so
that the problems inherent in the proposed feature won't bite you." I
generally agree, but I don't find that sufficient justification for
adding a feature that introduces so many pitfalls. Anyway, if it all
boils down to how you write manifests, then there are already ways you
can write manifests so that you get your desired behavior without DSL
changes (the inheritence-based approach I described in a previous
message, for one), or you can get an equivalent fairly easily if you
write your own ENC.
> 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.
You never have any way of *knowing* whether node Y is running a
webserver other than logging in and checking, especially if you're
speaking from a security perspective.
I don't dispute that the feature you propose might make your life
easier, but it would make a lot of other people's lives harder. I
don't think you appreciate the nature and scope of the difficulties
that would arise, and I don't accept "just write your manifests
differently" as an adequate response to them.
> That's good for security, good for auditing, good for performance, and good
> for piece of mind. :)
I'm all for security, auditing, performance, and peace of mind. I'm
also for ease of use, reliability, and backwards compatibility. And
world peace. My considered opinion is that the proposed feature would
be a net loss.
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.
