Open Stack

> From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
> ...
> Thank you for sharing this. It looks pretty impressive. Could you, 
> please some details about DSL syntax, if it is possible?

I will respond briefly, and pass your request along to the people working 
on that.

In the Weaver language there are distinct concepts for software 
configuration vs. things (such as VMs) that can host software configs.  As 
in the current software config work, there are distinct concepts for 
defining a software configuration vs. applying one to some particular 
infrastructure.  Weaver supposes that local configuration is described in 
Chef; Weaver adds a way of connecting chef variables across machines.  So 
you see, there are a lot of similarities with the current work on software 
config, which I support.

Weaver takes advantage of the power of Ruby metaprogramming to add pretty 
natural and concise constructs for modeling infrastructure and software 
config.  The source does not look like it is one level off, it looks like 
it is describing a thing rather than describing how to build a model of 
the thing (even though that is what it is actually doing).

Embedding in Ruby adds powerful and familiar support for abstraction and 
customized repetition in descriptions of distributed systems.  This is 
going to be hard to do nicely in a language (regardless of whether it uses 
JSON or YAML syntax) that is primarily for data representation.  One of 
the points of sharing this example was to show a system for which you 
would like such power.

What is the unique problem that Murano is addressing?  The current 
software config work can deploy multiple configs to a target.  Supposing 
that the local config (the non-distributed base configuration management 
tool involved, which is open in the current software config work) is 
expressed using something sufficiently powerful (chef and bash are 
examples), the local config language can do abstraction and composition in 
the description of local configuration.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140208/0c166276/attachment.html>