Trying to resurrect this thread without killing myself... Snipping
wherever possible.
On Nov 10, 2008, at 2:35 PM, Florian Grandel wrote:
>
>> My main conclusion here, though, is that you're talking about a
>> language that bears not a lot of resemblance to Puppet, in the end,
>> and if this is something you want, then I recommend starting by
>> essentially forking Puppet's parser and working from there.
>
> I didn't say that I want all this in practice. As a user I'd be
> completely happy with a very small change to the language (=class
> parameters).
I'm amenable to class parameters, although I don't know how they would
work, as I think classes shouldn't have names. Unless we did
something weird like:
class { webserver: ipaddress => "..." }
So I'm ok with your basic request, but I don't see it as a complete
syntactical proposal yet. Could you produce patches that provided
what you want?
>
> I think we were discussing: "Where could we go if there weren't
> compatibility limitations?" My rationale wasn't one of forking puppet
> but of discussing some idea of an "ideal" configuration language. The
> practical result I hope for is to avoid proliferation of (in my eyes)
> "difficult to learn" language constructs or some "bad" puppet recipes
> that I saw in the documentation.
Ok. FTR, not much I can do about "bad" code.
>> Would it be:
>>
>> webserver { : }
>>
>> Or maybe:
>>
>> webserver { webserver: }
>>
>> This is actually how Puppet started, and I got rid of it because of
>> how obviously unobvious they are.
>
> See the examples in my last post... The syntax would be:
>
> bundle webserver_node inherits node {
> webserver { par1=>..., par2=>... }
> database { par1=>..., par2=>... }
> }
>
> Or if you have no parameters then:
>
> bundle webserver_node inherits node {
> webserver
> database
> }
You've syntactical confusion here, though -- Puppet's current parser
would assume these are functions, not classes. You could try to
autodetect the difference, but I think that would be much worse.
> bundle mynode inherits node {
> firewall
> webserver { require => Firewall }
>
> # This is implicitly the same as:
> # firewall { "$name": }
> # webserver { "$name": require => Firewall["$name"] } !
> }
>
> When you think that there is something you cannot do without an
> include
> then please give me a specific example.
Your 'firewall' statement just can't work without getting rid of
functions, and probably wouldn't work even if we did. Therefore we'd
need to use 'include' or something similar to evaluate the function.
>
>> Introduction of the keyword 'self':
>>
>> I actually don't know what you're doing here, but you're using it in
>> all of your examples, so I figured I'd point it out.
>
> It's just a common way to provide separate namespaces for instance
> variables and local variables. I used a syntax similar to php, C++ or
> java. In Ruby "@..." does the same.
>
> Currently puppet does not distinguish between local variables and
> instance variables.
So you're also proposing adding instance variables to Puppet.
>
> Doing something like
>
> define(...) {
> ...
> $require = 5
> ...
> }
>
> raises an error. This is bad as it may cause maintenance trouble when
> introducing new parameters to a definition in puppet that may already
> exist as local variables.
This certainly does not raise an error:
notify { "Yay": }
define foo($bar) {
$require = Notify["Yay"]
notify { "$name $bar": }
}
foo { a: bar => b }
=> notice: Yay
notice: //Notify[Yay]/message: defined 'message' as 'Yay'
notice: a b
notice: //Foo[a]/Notify[a b]/message: defined 'message' as 'a b'
>> Does this mean that we could have multiple subinstances or whatever
>> you call them for a given node? That is, we could have webserver
>> { mynode: } and dbserver { mynode: }?
>
> No, you cannot have two "subinstances" for the same physical node.
>
> If webserver and dbserver both inherit from node then an instance
> for a
> given physical host can exist for one or the other but not both. If
> you'd try to do something like this then puppet should throw an error.
In other words, because the facts are only available in the node, you
can only ever have one class on the system that has access to the
facts. I don't think that will work.
> Facter variables have to be explicitly passed down from the node
> type to
> any bundle that needs it (see the above example again). This avoids
> global variables and improves encapsulation.
They're still as global as the current facts, they just start one
scope further down the tree. So slightly less global, I guess, but
people would just build their configs so they were effectively global.
>
>> This seems to be the crux of your argument -- that removing
>> syntactical variety is simpler and hides complexity -- but I'm not
>> convinced. Puppet's simplicity largely comes from its lack of
>> options
>> or complexity -- would you say LISP is simpler or more complex than
>> Puppet?
>
> The way you state it, it is not correct. Replace "simplicity" by "easy
> to learn" and "maintainable" and you are much closer to what I am
> after.
> IMO a language is "easy to learn" if it uses concepts that are already
> known to the majority of users when they start to learn it.
>
> I don't want to reduce syntactical variety. I want to...
> 1) reduce the number of new concepts that one has to learn to learn
> puppet.
> 2) reduce duplicate code and global variables to improve
> maintainability
> and extensibility.
I'm willing to give the benefit of the doubt, but I don't agree with
your conclusions about simplicity. Or rather, I don't think you've
proposed a complete, workable system. If you could come up with code
that provided this functionality, I'd be much more convinced.
>> I think you are missing a lot of corner cases (or maybe not-so-
>> corner)
>> that make it less so. In particular, the common case of a "class"
>> with no name or parameter is particularly jarring syntactically:
>>
>> webserver { : }
>
> See my examples in earlier posts and at the beginning of this
> message. I
> think that's a case I've thought about from the beginning.
Again, the syntax you've proposed conflicts with an existing syntax,
that for functions.
>
>> This gets silly on relationships, too; do I do:
>>
>> require => Webserver[]
>>
>> or:
>>
>> require => Webserver[webserver]
>
> Neither one nor the other, see the example at the beginning of this
> message.
This was 'require => Webserver'? I guess that's ok.
At this point, I think it's a question of code. I know that's a big
ask, but I think you can't see the complications from your proposals
until you go to implement them.
--
A little government and a little luck are necessary in life, but only a
fool trusts either of them. -- P. J. O'Rourke
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
