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

Angus Salkeld angus.salkeld at rackspace.com
Wed Mar 19 01:53:53 UTC 2014

On 19/03/14 04:32 +0400, Ruslan Kamaldinov wrote:
>Here is my 2 cents:
>I personally think that evolving Heat/HOT to what Murano needs for it's use
>cases is the best way to make PaaS layer of OpenStack to look and feel as a
>complete and fully integrated solution.
>Standardising these things in a project like TOSCA is another direction we all
>should follow. I think that TOSCA is the place where developers (like us),
>application developers and enterprises can collaborate to produce a common
>standard for application lifecycle management in the clouds.
>But before Murano contributors jump into direction of extending HOT to the goal
>of application (or system) lifecycle management, we need an agreement that this
>is the right direction for Heat/HOT/DSL and the Orchestration program. There are
>a lot of use cases that current HOT doesn't seem to be the right tool to solve.
>As it was said before, it's not a problem to collaborate on extending it those
>use cases. I'm just unsure if Heat team would like these use cases to be solved
>with Heat/HOT/DSL. For instance:
>- definition of an application which is already exposed via REST API. Think of
>  something like Sahara (ex. Savanna) or Trove developed in-house for internal
>  company needs. app publishers wouldn't be happy if they'll be forced to
>  develop a new resource for Heat

I think we could develop *something* like amazon's custom resource:

>- definition of billing rules for an application

The way to integrate with how OpenStack does this is to emit rpc notifications
that ceilometer picks up. Heat does this now for stacks and autoscaling groups.
I think what you might be getting at is possibly sending resource level infomation
so the operator could bill on specific resource types/applications.

So that is the metering, but the billing rules should be elsewhere (a consumer
of ceilometer).

>If everyone agrees that this is the direction we all should follow, that we
>should expand HOT/DSL to that scope, that HOT should be the answer on "can you
>express it?", then awesome - we can start speaking about implementation details.

If those two items are the only new features to Heat then I am sold.


>If it's not the direction these projects should follow then at least finding
>where Heat ends and Murano starts to avoid any functionality duplication would
>be great.
>On Wed, Mar 19, 2014 at 2:07 AM, Keith Bray <keith.bray at rackspace.com> wrote:
>> Georgy,
>> In consideration of the "can you express it" instead of the "who will
>> generate it," I see Heat's HOT evolving to support the expression of complex
>> multi-tier architectures and applications (I would argue you can already do
>> this today, perhaps with some additional features desired, e.g. Ability to
>> define cloud workflows and workflow execution rules which could come when we
>> have a workflow service like Mistral).  Therefore, I would encourage Murano
>> contributors to consider whether they can help make Heat sufficiently cover
>> desired use cases.  I have never viewed Heat templates as isolated
>> components of a multi-tier architecture.  Instead, a single template or a
>> combination of master/subordinate templates together (using references,
>> nesting, or inclusion) could express the complete architecture, both
>> infrastructure and applications.
>> If I've read your previous comments and threads correctly, you desire a way
>> to express System Lifecycle Management across multiple related applications
>> or components, whereby you view the System as a grouping of independently
>> developed and/or deployed (but systematically related) "components," whereby
>> you view Components as individual disconnected Heat templates that
>> independently describe different application stacks of the System.  Did I
>> get that correct?   If so, perhaps the discussion here is one of "scope" of
>> what can or should be expressed in a Heat template. Is it correct to state
>> that your argument is that a separate system (such as Murano) should be used
>> to express System Lifecycle Management as I've defined it here?  If so, why
>> could we not use the Heat DSL to also define the System?  The System
>> definition could be logically separated out into its own text file... But,
>> we'd have a common DSL syntax and semantics for both lower level and higher
>> level component interaction (a building block effect of sorts).
>> As for "who will generate it," ( with "it" being the Heat multi-tier
>> application/infrastructure definition) I think that question will go through
>> a lot more evolution and could be any number of sources: e.g. Solum, Murano,
>> Horizon, Template Author with a text editor, etc.
>> Basically, I'm a +1 for as few DSLs as possible. I support the position that
>> we should evolve HOT if needed vs. having two separate DSLs that are both
>> related to expressing application and infrastructure semantics.
>> Workflow is quite interesting ... Should we be able to express imperative
>> workflow semantics in HOT?  Or, should we only be able to declare workflow
>> configurations that get configured in a service like Mistral whereby
>> Mistral's execution of a workflow may need to invoke Heat hooks or Stack
>> Updates?  Or, some other solution?
>> I look forward to a design discussion on all this at the summit... This is
>> fun stuff to think about!
>> -Keith
>> From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: Tuesday, March 18, 2014 1:49 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
>> I see this in the following way - who will generate HOT template for my
>> complex multi-tier applications when I have only templates for components?
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list