I constantly get told I should just create a DSL in Ruby, instead of
having a separate, custom language. This has, unsurprisingly, come
up multiple times here at OSCON.
So, I decided I''d see if I could hack something up and see how it
looked. This is the first thing I could come up with in terms of the
basic functionality:
#!/usr/bin/ruby
class Base
file "/etc/passwd",
:owner => "root",
:group => "root",
:mode => 0644,
:source => "puppet://puppet/..."
end
class BSD < Base
file "/etc/passwd",
:group => "wheel"
end
include :bsd
The implementation I have (which is about 105 lines of code) supports
the same kind of overriding that Puppet''s language supports, but it
doesn''t do anything else. I haven''t tried to model define
statements, since I figure people would just use the normal Ruby
methods. I also haven''t bothered to set up any of the Facts in the
script or anything like that, and currently my code just dumps the
created configuration, rather than applying it.
I have been thinking that maybe Puppet could support loading
''.rb''
files written in this kind of code, or ''.pp'' files written in
current
Puppet code, and it should be possible to otherwise treat them the
same -- puppetmasterd would parse everything and wait for
connections, while puppet would immediately apply the configuration.
I wouldn''t expect you to be able to mix files -- all of them would
be .pp, or all of them would be .rb.
I haven''t thought much about how this would look in real life, but I
figured I''d at least look at what a DSL in Ruby would look like and
see if it was an incredibly bad idea.
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?
--
Luke Kanies
http://madstop.com
615-594-8199
On Wed Jul 26, 2006 at 14:13:52 -0700, Luke Kanies wrote:>I haven''t thought much about how this would look in real life, but I >figured I''d at least look at what a DSL in Ruby would look like and >see if it was an incredibly bad idea. > >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?Yeah. This sounds like the DSL I started writing on top of Python to generate cfengine inputs, so the concept isn''t foreign to me. I''m still in two minds whether it''s a good thing; you can get up to some weird stuff and it''s confusing to other admins. I *like* the idea of a domain specific language, but you''ve already got one, and it''s been designed already to be very expressive in the domain of configuration management. Trying to reimplement that DSL using the constraints of Ruby, whilst worth it merely to explore the idea, I think is probably going to be unproductive. (Besides, if you did this, then I really would have to learn myself Ruby ;-)
On Wed, Jul 26, 2006 at 02:13:52PM -0700, Luke Kanies wrote:> I constantly get told I should just create a DSL in Ruby, instead of > having a separate, custom language. This has, unsurprisingly, come > up multiple times here at OSCON.DSLs being the hot-topic of the day, it''s unsurprising that everyone has an opinion on the topic. I remember when I first learnt lex/yacc -- suddenly every problem could be solved with a grammar. This isn''t much different, really.> So, I decided I''d see if I could hack something up and see how it > looked. This is the first thing I could come up with in terms of the > basic functionality: > > #!/usr/bin/ruby > > class Base > file "/etc/passwd", > :owner => "root", > :group => "root", > :mode => 0644, > :source => "puppet://puppet/..."You might want to "class Base < Puppet::Class" for cleanliness, but if we consider these puppet scripts as totally separate, then adding the type creators under Object might not be considered quite so naughty. It just seems... icky.> class BSD < Base > file "/etc/passwd", > :group => "wheel" > end > > include :bsdWe''ll need to change the keyword for loading another class -- ''include'' is already taken by Ruby, and overloading that is going to be... Entertaining.> The implementation I have (which is about 105 lines of code) supports<goldmember>Toight loik a toiger!</goldmember>> I have been thinking that maybe Puppet could support loading ''.rb'' > files written in this kind of code, or ''.pp'' files written in current > Puppet code, and it should be possible to otherwise treat them the > same -- puppetmasterd would parse everything and wait for > connections, while puppet would immediately apply the configuration. > I wouldn''t expect you to be able to mix files -- all of them would > be .pp, or all of them would be .rb.Awwww, that''s no fun! It also kinda upsets the migration path -- I know *I* don''t want to rewrite all of my existing classes in .rb just to be able to put ''if'' statements in a couple of them.> I haven''t thought much about how this would look in real life, but I > figured I''d at least look at what a DSL in Ruby would look like and > see if it was an incredibly bad idea. > > 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.That''s the tricky problem -- I quite like the idea that the Puppet manifest description language is fairly tightly constrained. It doesn''t give the not-quite-so-133t quite the same ability to make a complete mess of things as what straight Ruby does. It also feels easier to learn for someone who is coming from a don''t-know-Puppet-or-Ruby background -- if you''re going to have to learn the syntax one of them, I think that Puppet might be a bit easier. Conversely, if you already know Ruby, a small Ruby DSL would no doubt be easier to pick up. Turning around and speaking from a pro-DSL standpoint, it seems like the parser is a bit of a bottleneck in evolving the language -- not necessarily so much from an absolute features point of view (after all, public objects came on the scene fairly quickly) but having to think about designing the fundamental details of the language (like boolean operators and if, to take a recent example) distracts from other, more interesting features. Also, you''re the only one who really understands the deep magic in and around the parser, I think, so it''s a bit of a single-point-of-failure and general blocker. Not that having random dabblers making core language changes is necessarily something you want to encourage... I''m terribly conflicted. I do like writing Rails code specifically because I know I''ve got the entire power of the Ruby language behind me, and there have been a few times where being able to drop a tiny fragment of Ruby into a manifest would have been a godsend. But keeping the language simple, easily auditable, and above all constrained, is also important. I think though, at the end of the day, my power-hungry side would win out on this. I console myself with the fact that Puppet users have many other ways to hurt themselves -- locally-written types and shell scripts, so giving them more power in the manifest description language (which is air-gapped from the actual end-machine by the manifest transfer from server to client) probably isn''t the worst thing people are going to be able to do, if they want to have an attack of the dumbs.> Any comments? Should I commit this to subversion, just to keep it > around in case people want to mess with it?I think it should definitely go into svn, it''s worth keeping around. - Matt -- I seem to have my life in reverse. When I was a wee''un, it seemed perfectly normal that one could pick up the phone and speak to anybody else in the world who also has a phone. Now I''m older and more experienced, I''m amazed that this could possibly work. -- Peter Corlett, in the Monastery
On Thu, Jul 27, 2006 at 09:18:20AM +1000, Jamie Wilkinson wrote:> (Besides, if you did this, then I really would have to learn myself Ruby ;-)I just changed my vote from "maybe DSL" to "definitely DSL, right now!". You need to learn Ruby, jaq. It''ll warp your mind. It is not just Python with better marketing. - Matt
On Jul 26, 2006, at 5:35 PM, Matthew Palmer wrote:> > I just changed my vote from "maybe DSL" to "definitely DSL, right > now!".Committed, as everyone likely saw.> You need to learn Ruby, jaq. It''ll warp your mind. It is not just > Python > with better marketing.I agree, completely. It must be said that I started Puppet, in ruby, long before the Rails craze, and I wrote it in Ruby for a reason -- Ruby kicks ass. If you program much and you haven''t tried Ruby, do so. Write something trivial, whatever, but try it. -- Luke Kanies http://madstop.com 615-594-8199
On Jul 26, 2006, at 5:35 PM, Matthew Palmer wrote:> > I just changed my vote from "maybe DSL" to "definitely DSL, right > now!".Committed, as everyone likely saw.> You need to learn Ruby, jaq. It''ll warp your mind. It is not just > Python > with better marketing.I agree, completely. It must be said that I started Puppet, in ruby, long before the Rails craze, and I wrote it in Ruby for a reason -- Ruby kicks ass. If you program much and you haven''t tried Ruby, do so. Write something trivial, whatever, but try it. -- Luke Kanies http://madstop.com 615-594-8199
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. 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. 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... Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ?ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
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.> 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: * 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. * 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 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. - Matt
Hi Matt, everyone! On Saturday 29 July 2006 09:11, Matthew Palmer wrote:> > 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.Yes and no. I was thinking about having some kind of (legacy/management) database which already has information I would want to use to configure puppets. Using ruby as DSL, I could query the database everytime a puppet asks for its manifest. Using a .pp compiler, I could regenerate the .pp scripts everytime the database changes. Implementing a kind of SQL type which takes a SELECT statement like: sql { "SELECT name, mode, owner, group, content FROM files WHERE hostname $hostname": } or even sql { default-files: type => file, fields => "name, mode, owner, group, content" table => files, where => "hostname = $hostname" } that would go in the spirit of the declarative .pp philosophy.> > 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.As soon as the puppetmaster serializes the manifest for the client ... Architecturally, this already defines the interfaces for the manifest components: * Input: used by the server to create the in-memory representation ** .pp parser ** .rb scripts/objects * De-/Serializer: translation from/to a static string representation of a configuration ** yaml for "native" clients ** XML for others * Performer: Applies the in-memory representation to a system Currently these parts are not very separated. Exposing interfaces for these parts would enable a more flexible usage by e.g. writing a custom Input/Serialisation component. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ?ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
On Sat, Jul 29, 2006 at 03:37:10PM +0200, David Schmitt wrote:> On Saturday 29 July 2006 09:11, Matthew Palmer wrote: > > > 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. > > As soon as the puppetmaster serializes the manifest for the client ...Actually, I would expect that the wrapper code to invoke the Ruby manifest and get something useful out would be maybe 3 lines.> * De-/Serializer: translation from/to a static string representation of a > configuration > ** yaml for "native" clients > ** XML for othersDefine "native" here -- YAML is a well-specified standard for the serialization of data that compares quite well to XML for most data representation tasks. It isn''t even a Ruby thing, really -- it started in the Perl world, IIRC.> Currently these parts are not very separated. Exposing interfaces for theseI don''t know the code base backwards, but so far I''ve been pretty happy with the low coupling present in the various parts of Puppet. - Matt -- New Yankee Workshop isn''t a "how to" for home hobbyists, it''s "Baywatch" for powertool fetishists. -- Geoff Kinnel, ASR
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
On Jul 29, 2006, at 8:37 AM, David Schmitt wrote:> > Yes and no. I was thinking about having some kind of (legacy/ > management) > database which already has information I would want to use to > configure > puppets. Using ruby as DSL, I could query the database everytime a > puppet > asks for its manifest. Using a .pp compiler, I could regenerate > the .pp > scripts everytime the database changes.The mechanism for each of these, depending on your willingness to use Ruby, would probably be pretty similar. If I had a bunch of data outside of Puppet that I wanted in it, I''d just create a function to turn that data into Puppet elements. This function would work equivalently in both the language and the DSL. Puppet does not currently autoload functions, but I just added a feature request for that and it''s easy to do.> Implementing a kind of SQL type which takes a SELECT statement like: > > sql { "SELECT name, mode, owner, group, content FROM files WHERE > hostname > $hostname": > } > > or even > > sql { default-files: > type => file, > fields => "name, mode, owner, group, content" > table => files, > where => "hostname = $hostname" > } > > that would go in the spirit of the declarative .pp philosophy.Yep, it should be pretty easy to model the entire Puppet configuration in a database. Obviously the objects are easy to model, but even the control structures shouldn''t be all that difficult.> As soon as the puppetmaster serializes the manifest for the client ...What do you mean? Puppetmasterd does serialize the compiled client configuration, into YAML (mostly because I was too lazy to figure out how to do it in XML, but I''m perfectly willing to switch to that if someone is willing to contribute the code or pay for the work or whatever).> Architecturally, this already defines the interfaces for the manifest > components: > > * Input: used by the server to create the in-memory representation > ** .pp parser > ** .rb scripts/objects > > * De-/Serializer: translation from/to a static string > representation of a > configuration > ** yaml for "native" clients > ** XML for othersThere''s a pretty important "compile" step in here, though. Converting from the configuration that specifies for everyone to a host-specific configuration is pretty important, and how you get the compiled configuration to the client is significantly less important. Right now it''s in YAML, but it''s pretty darn easy to switch to something else -- I''ve already even got the hooks for using and specifying a different format.> * Performer: Applies the in-memory representation to a system > > Currently these parts are not very separated. Exposing interfaces > for these > parts would enable a more flexible usage by e.g. writing a custom > Input/Serialisation component.Actually, these steps are entirely decoupled. There are clearly separate entities for each step, and they have clean interfaces to the surrounding steps. See http:// reductivelabs.com/projects/puppet/documentation/howitworks.html for all of the details, but the short of it is: The parser converts from text to a parse tree. The interpreter creates a scope and converts from a parse tree to an individual host''s configuration. The Master server serializes and sends the individual configuration to the client. The Master client turns that serialized configuration into a collection of Puppet::Type instances and also handles applying those instances. As I said, the interfaces between these objects are all pretty darn clean; if you disagree, please provide detail, as I would consider that a bug and fix it ASAP. One of my primary goals throughout this whole process has been to keep everything as decoupled as possible. -- Luke Kanies http://madstop.com 615-594-8199
On Wed, 2006-07-26 at 14:13 -0700, 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?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. 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. 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. 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. 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. David
On Thu, 2006-07-27 at 10:41 -0700, Luke Kanies wrote:> If you program much and you haven''t tried Ruby, do so. Write > something trivial, whatever, but try it.I completely agree with that, though you also need to remember that Ruby is still a bit of an exotic language for a lot of people and there are plenty of people who hesitate learning it (I know quite a few of them ;) David
David Lutterkort wrote:> > I completely agree with that, though you also need to remember that Ruby > is still a bit of an exotic language for a lot of people and there are > plenty of people who hesitate learning it (I know quite a few of them ;)They should go listen to some of the Rails hypesters, then; apparently it''s going to take over the world. :/ -- I respect faith, but doubt is what gets you an education. -- Wilson Mizner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
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