Open Stack

Hi Mike,

Thank you for clarification. I like your approach with Ruby and I think
this is a right way to solve such tasks like DSL creation. In Murano we use
Yaml and python just to avoid introduction of a whole new language like
Ruby to OpenStack.

As for software configurations in heat, we are eager to have it available
for use. We use Heat in Murano and we want to pass as much as possible work
 to Heat engine. Murano itself is intended to be an Application Catalog for
managing available application packages and focuses on UI and user
experience rather then on deployment details. We still use DSL for several
things, have something working while waiting for Heat implementations, and
to have imperative workflow engine which is useful when you need to
orchestrate complex workflows. The last part is very powerful when you need
to have an explicit control on deployment sequence with conditional
branches orchestration among several different instances. When Mistral will
be available we plan to use its workflow engine for task orchestration.

Again, thank you for sharing the work you are doing in IBM. This is very
good feedback for OpenStack community and helps to understand how OpenStack
components used in enterprise use cases.

Thanks
Georgy


On Sat, Feb 8, 2014 at 10:52 AM, Mike Spreitzer <mspreitz at us.ibm.com> wrote:

> > 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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140208/778d1d1d/attachment.html>