Hi Mike,

Thank you for sharing this. It looks pretty impressive. Could you, please
some details about DSL syntax, if it is possible?

In our Murano project we are also solving the problem of Heat template
generation. At his moment we are working on a new DSL for Murano to move
from XMLs based DSL to simplified lightweight  Yaml based DSL syntax. Here
is an example how this new DSL looks like.

Using Murano DSL it is possible to combine multiple Applications defined by
their manifests and then Murano engine will create Heat template for the
whole environment by using Heat snippets available in Murano.


On Thu, Feb 6, 2014 at 11:16 PM, Mike Spreitzer <mspre...@us.ibm.com> wrote:

> Thanks to work by several colleagues, I can share a non-trivial Heat
> template for a system that we have been using as an example to work.  It is
> in the TAR archive here:
> https://drive.google.com/file/d/0BypF9OutGsW3Z2JqVTcxaW1BeXc/edit?usp=sharing
> Start at connections.yaml.  Also in the archive are other files referenced
> from that template.
> The system described is a non-trival J2EE application, IBM Connections.
>  It is a suite of collaboration applications, including things like wiki,
> file sharing, blogs, and directory of people.  It is deployed into a system
> of WebSphere application servers.  The servers are organized into four
> "clusters" of four servers each; each server is a VM with a single
> application server.  The applications are partitioned among the four
> clusters.  There is also a "deployment manager", a VM and process used to
> manage the application servers.  There is also a pair of HTTP servers ---
> the "IBM Http Server" (IHS), basically the Apache httpd.  There is also a
> database server, running DB2.  This system makes reference to an external
> (not deployed by the template) NFS server and an extenal LDAP server.  The
> template describes both the VMs and the configuration of the software on
> them.  The images used have the IBM software installed but not configured.
> This template (and the referenced files) were produced by automatic
> translation from sources expressed in Weaver into a Heat template that is
> ready to run.  Weaver is a system for describing both infrastructure and
> software configuration (based on Chef).  A Weaver description is a modular
> Ruby program that computes a model of the infrastructure and software;
> Weaver includes certain constructs tailored to this job, you may think of
> this as a DSL embedded in Ruby.  The cross-machine dependencies are
> described abstractly in the source, connected to things in the Chef.
>  Weaver uses an implementation that is different from the one being
> implemented now; Weaver's is based on communication through Zookeeper.  You
> will see in the Heat the convolution of the user's input and Weaver's
> implementation (as Heat has no built in support for this mechanism).  (I
> say these things not as a sales pitch, but to explain what you will see.)
> You will not be able to instantiate this template, as it has several
> references to external servers that are part of our environment, including
> those mentioned above.  In fact, I have edited the external references to
> remove some private details.  This template is presented as an example to
> look at.
> Regards,
> Mike
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Georgy Okrokvertskhov
OpenStack Platform Products,
Tel. +1 650 963 9828
Mob. +1 650 996 3284
OpenStack-dev mailing list

Reply via email to