On Tue, Oct 19, 2010 at 01:36:25PM +0200, Felix Frank wrote:
>
> Subclasses that effectively disable a class are a sound concept.
Subclasses which disable a resource are a sound concept; subclasses
which attempt to negate a claass present many problems, some of which I
have described, none of which you hae addressed.
> How
> this has to be achieved in any specific case can be somewhat
> mind-boggling,
Yes, indeed. All the problems of virtual resources, other included
classes, requirement to extend the disabling class every time the basic
class is changed and so on. And you've presented no solutions to any of
those.
> but the variable approach has severe limitations of its own.
>
> 1. Where is the variable set? You have probably no problem when using
> external node definition, but not everybody does.
You can do it in an internal node definition too. Is there a law
against node definitions in your manifests? But let's assume somebody
doesnt' want to or cannot use nodes. That isn't a problem; I've
designed Puppet configurations that used no nodes at all, or a default
node which simply included a class based on the node's hostname. Still
works - just declare the variable at the right level.
> You cannot define the
> variable in an arbitrary part of your manifest, because you can be
> afflicted by both ordering and scoping issues.
I wouldn't try to declare it in an arbitrary location. I would declare
it in an appropriate location.
>
> 2. The concept of dynamic scoping is going away in future versions (at
> least that is what seems to be a community consensus). Again, if you can
> globally assign the variable value to your node, this is not a problem.
It's not that I'm in love with the way Puppet uses variables - I
certainly amd not - my objection is to the concept of trying to negate a
class by individually trying to break or undo all it's effects. That
latter option is a horrible mess. Unless the community also proposes to
do away with "if", "case" and selectors, there is always going to be a
way of saying "if <condition> { include ldap::client }" and that is
always going to be a better solution for the problem *as described by
the original poster*, which is what I was answering.
> But if you want to for every node that includes class B to automatically
> not include class A, you're out of luck (this is true in many cases
> today already, because of the scoping issues).
Well, you've finally given an example that raises a genuine problem, but
the first thing to say is that it's not the problem described by the
poster. Secondly, the problem you describe can be solved by some
variant of
if $variable {
include A
} else {
include B
}
Even if we outlaw simple variables, there are other ways to to signal
state; parameterized classes, defines, creative abuse of virtual
defines, all of them are better than the idea of negating a class
resource by resource.
>
> Variables are about as far as you can get from a panacea in the puppet
> DSL. Granted, class inheritance can be clumsy, awkward and
> unmaintainable in many cases.
Class inheritance is very elegant when used for what it is good for. It
is bad for the purposes of the original poster.
> But all that and more applies to variables
> as well, and it seems to me that variables are going to become a lot
> less useful for such purposes in the future.
Wonderful. As I said, I'm not in love with Puppet's variables. I've
worked with declaritive languages before - done major projects in XSLT
and XSLT - and I'll be delighted to see more structured, less messy ways
of working. I'd be even more delighted to see some of what are
currently functions become genuine keywords. But if you're telling me
that the community is not just proposing to remove dynamic variable
scope but also to remove the ability to say "if <condition> { include
class }", not provide any alternatives and force people to have to
clumsily override every resource in a class which they never wanted to
include in the first place, then I'm afraid that the community is an
ass. Hopefully, that's not what you're telling me.
--
Bruce
It is impolite to tell a man who is carrying you on his shoulders that
his head smells.
--
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.
