[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:
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/crpg-walkthrough.html

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

-Angus

>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.
>
>
>Thanks,
>Ruslan
>
>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
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list