[Puppet-users] Pupppet Ruby DSL

David Schmitt
Sat, 29 Jul 2006 06:37:10 -0000

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