[Puppet-users] Pupppet Ruby DSL

Luke Kanies
Mon, 31 Jul 2006 08:41:01 -0000

On Jul 29, 2006, at 2:11 AM, Matthew Palmer wrote:

> On Fri, Jul 28, 2006 at 09:01:34AM +0200, David Schmitt wrote:
>> On Wednesday 26 July 2006 23:13, Luke Kanies wrote:
>>> I still don''t know.  It feels like it''s basically
as restricted as
>>> the language, but certainly it''s a heckuva lot less code
than
>>> Puppet''s parser is.
>>>
>>> Any comments?  Should I commit this to subversion, just to keep it
>>> around in case people want to mess with it?
>>
>> The thing that bothers me, is: what''s the use-case? Most
>> applications seem to
>> be doable as well by using some .pp compiler. e.g. creating a
>> configuration
>> from a tripwire database.
>
> When you say ".pp compiler", do you mean a tool that writes a
Puppet
> manifest (.pp) file by using information from another source?  I
don''t
> really see how it''s any harder to do that if the language is Ruby
> underneath
> than if it''s the manifest language.

I agree here; I''d expect that the DSL and the Puppet language would
continue to look very similar for the foreseeable future, and I don''t
see it as being any more complex to do a given task in one than the
other.  Well, rather, on aggregate I expect them to be similar; most
likely, each will be better at some things than others.

As to the use-case, I didn''t write it because I thought there was a
use-case, I wrote it because every Ruby guy I ever talk to says, "Why
don''t you just use a DSL?", and I don''t have an airtight
answer.  I
figured I should at least try it out and see if it''s worth anything.

It''s still not usable yet, since you can''t do defines in it,
and it
seems necessary to have a translator from one to the other, but it''s
a decent start at deciding whether the extra effort of a language is
worth it.

>> In contrast to the current way of slowly migrating useful defines
>> ans custom
>> types into puppet proper, allowing ruby in the configuration will
>> reduce the
>> need to push such things upstream.
>
> I thought this at first, too, but I''ve changed my mind there.  You
> see, the
> Ruby-based configuration specification gets turned into the same
> intermediate form before it goes to the client -- it''s a big fat
> YAML file
> that describes all of your objects.  Being able to write Ruby in your
> manifest does not allow you to manipulate things any better.  What
> it does
> give you is:

I was concerned about this same thing previously, but since the DSL
just creates transportable objects, it''s pretty limited in its affect.

> * The ability to dynamically create manifests directly, using
> Ruby.  This
> actually goes to your initial comment, above, about creating
> manifests from
> other sources of host data, and it makes it *easier* than if you
> have to
> write out a .pp file.

Yep.

> * A much reduced burden of having to write the base language
> primitives
> yourself to describe the manifest, because you''ve got Ruby as your
> parser
> and interpreter.  Time saving.

And this is definitely getting to be a problem.  There are a lot of
things I want to do in the language that I am finding it difficult to
design or get the time for.  Many of those things will still require
the same development effort, since they''re more about metaparams
than syntax (e.g., adding hooks for controlling transactions), but at
least some of them (e.g., ''if'' and operators) are already done
in Ruby.

>> And last but not least, it''s probably not much trouble to
write a
>> grammar that
>> accepts .pp files and does something sensible with them
>> (translating to xml,
>> creating statistics, querying a configuration of a host, cross
>> references)
>> using ruby as DSL one can use the ruby tools for that, but only
>> them. This
>> seems to balance out...
>
> This is a valid concern.  It is almost certainly going to be harder
> to parse
> a Ruby script than a .pp file.  However, with the .pp language
> growing more
> complex to support more operations, you''d have a bit of a job
> making sure
> you had a completely valid parser in another language anyway.  I''d
> suggest,
> if you''re looking for a data form of a manifest to read, just use
the
> localconfig.yaml file.

Grammars are always difficult, no matter what.  A DSL could actually
be easier in the end, because one could parse it in different
contexts -- e.g., we could have one DSL class that directly results
in the equivalent of Puppet''s existing grammar, and another that just
creates the equivalent of a parse tree, which you could then manipulate.

I think the language is still the right approach, but I''m willing to
spend a little time mucking around in a DSL, anyway.

--
Luke Kanies
http://madstop.com
615-594-8199