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

Georgy Okrokvertskhov gokrokvertskhov at mirantis.com
Thu Mar 27 15:42:18 UTC 2014

On Wed, Mar 26, 2014 at 11:25 AM, Keith Bray <keith.bray at rackspace.com>wrote:

> 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 think that this is a wrong way to go. First of all there is an issue with
separation of concerns as you will have one super-template which will
describe the whole world. UI part is only one of the use cases, but when
Murano will need some extra parameter will it go to HOT? When Solum will
need to define application build sequence to make an app binary from source
will this also go to HOT?

I think the reason for such talks was the fact that Heat engine accepts
only a single file as an input. Which is completely understandable as Heat
engine is designed to process a template which describes a set of resources
and their relations.

While we talk with our customers who want use Murano they are happy to have
multiple files keep each one small and simple. In Murano UI definition is a
separate file and application developer can have multiple UI file
definitions to quickly change look and feel without changing the deploymen
template part of application at all. Heat supports template nesting, this
is no obvious how the UI for this case will be rendered as this nesting
will be processed by Heat engine and final set of resources will be
produced by engine.

I don't see a big difference in learning between one huge DSL which covers
the all possible aspects and a set of small simpler DSLs focused on each
specific area. Having one big DSL is worse as the user can construct some
complex structures mixing the DSL functions from different are. It will be
a nightmare to create an engine which will validate and process such

> 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.

I just think this is a conceptually wrong. The whole idea of OpenStack to
have a clean set of API\components focused on specific functionality. Cloud
users want to have VMs with attached volumes and networks but is does not
mean that it should be single service in OpenStack. This is a power of
OpenStack which shows that the proper separation of concern and having
multiple services is a right way which allow one to move forward fast
making the development process for each service very effective due to
narrow scope and functionality focus.

I am glad to hear that you want to have something higher up to stack that
the current available functionality. I think this support our observation
of a huge demand for such higher level functionality in OpenStack. At the
same time I am against the proposed way of doing that by extending the
Orchestration program mission moving it to upper levels. Having clean
layers responsible for particular area is a benefit and strong side of
OpenStack from its global architecture view point.

> >  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
> >Lifecycle
> >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.

I think that the HOT template generation is not a key feature of Solum. It
is just a details of implementation. Other services like TripleO also
generates Heat templates but it does not mean that it is their primary

ALM is a broad term. I think Solum has a different area of responsibility
covering the Application Development area which does covered in OpenStack
The high level goals listed on Solum.io are:

   - Provisioning Speed
   - CI/CD
   - Git Push
   - Integration with common IDE's (Eclipse, IntelliJ, etc)
   - Application lifecycle management(connected environments - Dev, Test,

Given that I don't see the huge overlap here with Murano functionality as
even if Solum stated that as a part of solution Heat template will be
generated it does not necessarily mean that Solum itself will do this. From
what is listed on the Solum page, in Solum sense - ALM is a  way how the
application build from source promoted between different CI\CD environments
Dev, QA, Stage, Production. Solum can use other service to do this keeping
its own focus on the target area. Specifically to the environments - Solum
can use Murano environments which for Murano is just a logical unity of
multiple applications. Solum can add CI\CD specific stuff on top of it
keeping using Murano API for the environment management under the hood.
Again, this is a typical OpenStack approach to have different services
integrated to achieve the larger goal, keeping services itself very focused.

> -Keith
> [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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140327/43d1e48c/attachment.html>

More information about the OpenStack-dev mailing list