[Puppet-users] Pupppet Ruby DSL

Luke Kanies
Mon, 31 Jul 2006 16:03:54 -0000

David Lutterkort wrote:
>
> I guess it all depends ;) Going from the current puppet language to
> embedding in Ruby gives you the full power of Ruby, and gives up some of
> the abstraction that the current puppet language enforces. When you
> embed in Ruby, you completely lose control of what people do in their
> manifests (e.g., connect to some other server and get some information
> from that) It seems that that would make it much harder to convince
> people that a given manifest doesn''t have any nasty side effects.

For remote compiles, the restrictions are the same -- I transfer a list
of Transportable objects, and that''s it.

For local compiles, it''s probably murkier because you could get crazy
if
you wanted.

At this point I''m going to leave it around as an experiment, at least
so
I can point all of the "Puppet should use a DSL!" complainers at it
and
say, "you want one, there you go, but you''re on you''re
own".

> Right now, it''s also pretty clear what the input and output of a
> manifest are: in go the facts (and not much else) and out comes a list
> of transportable objects. With an embedded Ruby language, this becomes a
> lot murkier.

Well, the other input is the manifests themselves, and this doesn''t
really change with a Ruby DSL, except that those Ruby manifests can also
bring in other info (but then, so can the Puppet manifests, using
templates).

> To me there is a fundamental difference between e.g. Rails and Puppet,
> in that when you write a rails app you are really writing a ruby app,
> and you want some conveniences for things that are frequently needed in
> a webapp. Writing a puppet manifest to me is much less about writing a
> ruby program, and more giving a static description of what a given
> system should look like.

I fundamentally think of Puppet as a programming language, and the
programs people will write in Puppet will provide services like LDAP and
OpenOffice, so I don''t entirely agree.

The question is just what the best way to create that configuration is.

> As for the example you gave, I am not sure if a Ruby class is really a
> perfect fit for a puppet class; for example, multiple inheritance in
> puppet would make perfect sense, given the restrictions on elements that
> can be applied to a given host, while ruby (for good reason)
doesn''t
> support multiple inheritance.

I agree, but it sure didn''t take many lines of code, did it?  :)

This was just an example, and my question was more, is this a throw-away
example, or something I should keep around just in case?

> Another good question in this context is where exactly the line of
> abstraction should run. Right now there are two: one is given by the
> transportable objects, and the other by the manifests themselves. If
> manifests ever need to be communicated to something else (a DB, a
> non-Ruby app) a separate puppet language is definitely needed.

Yeah, and that''s been my primary motivation for using a separate
language all along, and it will remain that way.

The real trouble in writing Puppet''s language is one of expression, and
that problem doesn''t go away with a DSL, it just gets different.  I
still don''t know how to talk about transactional control or error
handling, for instance.

--
I respect faith, but doubt is what gets you an education.
         -- Wilson Mizner
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com