[openstack-dev] [Murano][Heat] MuranoPL questions?

Keith Bray keith.bray at RACKSPACE.COM
Wed Mar 26 18:25:05 UTC 2014

On 3/25/14 11:55 AM, "Ruslan Kamaldinov" <rkamaldinov at mirantis.com> wrote:

>* Murano DSL will focus on:
>  a. UI rendering

One of the primary reasons I am opposed to using a different DSL/project
to accomplish this is that the person authoring the HOT template is
usually the system architect, and this is the same person who has the
technical knowledge to know what technologies you can swap in/out and
still have that system/component work, so they are also the person who
can/should define the "rules" of what component building blocks can and
can't work together.  There has been an overwhelmingly strong preference
from the system architects/DevOps/ApplicationExperts I [1] have talked to
for the ability to have control over those rules directly within the HOT
file or immediately along-side the HOT file but feed the whole set of
files to a single API endpoint.  I'm not advocating that this extra stuff
be part of Heat Engine (I understand the desire to keep the orchestration
engine clean)... But from a barrier to adoption point-of-view, the extra
effort for the HOT author to learn another DSL and use yet another system
(or even have to write multiple files) should not be underestimated.
These people are not OpenStack developers, they are DevOps folks and
Application Experts.  This is why the Htr[2] project was proposed and
threads were started to add extra data to HOT template that Heat engine
could essentially ignore, but would make defining UI rendering and
component connectivity easy for the HOT author.

I'm all for contributions to OpenStack, so I encourage the Murano team to
continue doing its thing if they find it adds value to themselves or
others. However, I'd like to see the Orchestration program support the
surrounding things the users of the Heat engine want/need from their cloud
system instead of having those needs met by separate projects seeking
incubation. There are technical ways to keep the core engine "clean" while
having the Orchestration Program API Service move up the stack in terms of
cloud user experience.

>  b. HOT generation
>  c. Setup other services (like put Mistral tasks to Mistral and bind
>     them with events)
>Speaking about new DSL for Murano. We're speaking about Application
>Management. There are a lot of existing tools - Heat/HOT, Python, etc,
>but none
>of them was designed with ALM in mind as a goal.

Solum[3] is specifically designed for ALM and purpose built for
OpenStack... It has declared that it will generate HOT templates and setup
other services, including putting together or executing supplied workflow
definition (using Mistral if applicable).  Like Murano, Solum is also not
an OpenStack incubated project, but it has been designed with community
collaboration (based on shared pain across multiple contributors) with the
ALM goal in mind from the very beginning.


[1] I regularly speak with DevOps, Application Specialists, and cloud
customers, specifically about Orchestration and Heat.. HOT is somewhat
simple enough for the most technical of them (DevOps & App Specialists) to
grasp and have interest in adopting, but their is strong push back from
the folks I talk to about having to learn one more thing... Since Heat
adopters are exactly the same people who have the knowledge to define the
overall system capabilities including component connectivity and how UI
should be rendered, I'd like to keep it simple for them. The more we can
do to have the Orchestration service look/feel like one thing (even if
it's Engine + Other things under the hood), or reuse other OpenStack core
components (e.g. Glance) the better for adoption.
[2] https://wiki.openstack.org/wiki/Heat/htr
[3] http://solum.io

More information about the OpenStack-dev mailing list