OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tosca] Heat and the Simple Profile


Hi Zane,

Welcome to the TC. I'm sure we will all benefit from your unique perspective as the TC develops the YAML rendering of the TOSCA Simple Profile. FYI, please feel free to bring specific contributions and suggestions to our JIRA issue on the topic (1). Other TC members are also strongly encouraged to do the same, of course. 

(1) https://tools.oasis-open.org/issues/browse/TOSCA-7

Thanks,
Paul 


-----Original Message-----
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Thomas Spatzier
Sent: Sunday, February 23, 2014 12:44 PM
To: Zane Bitter
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Heat and the Simple Profile

Hi Zane,

it is great that you are bringing up this discussion an I am glad those thoughts came from you as a Heat core member. Let me try to answer some of your questions and comments on your thoughts below.

<tosca@lists.oasis-open.org> wrote on 21/02/2014 16:45:42:
> From: Zane Bitter <zbitter@redhat.com>
> To: tosca@lists.oasis-open.org
> Date: 21/02/2014 16:45
> Subject: [tosca] Heat and the Simple Profile Sent by: 
> <tosca@lists.oasis-open.org>
>
> Greetings,
> For those of you who don't know me already, I am one of the core 
> developers of the OpenStack Orchestration (Heat) project. I've been 
> observing the work of the TOSCA TC since around the beginning of the 
> year, and I wanted to take the chance to help y'all get to know Heat a 
> bit better so we can all figure out where it fits in to the picture 
> with respect to the TOSCA simple profile.
>
> There was some discussion at last week's TC meeting over whether there 
> ought to be a bijective mapping between TOSCA's YAML Simple Profile 
> and Heat Orchestration Templates (HOT). A couple of interesting points 
> came up in the discussion:
>
> Matt mentioned that Heat does not attempt to do "modelling". To my 
> mind, modelling is what Heat does - though, I confess, poorly on 
> occasion. The caveat is that we are only trying to model concrete 
> classes of infrastructure that actually exist in OpenStack (e.g. an 
> OpenStack Compute server), rather than general classes (e.g. any 
> server). So I'd like to learn more about what "modelling" means in the 
> TOSCA context to find out if that is indeed the source of our differing definitions.

I think you already brought up the point where TOSCA and Heat differt (at least at a first glance): Heat _does_ modeling, but it does it based on very concrete resource types (basically) all the resources you can get on OpenStack. TOSCA itself, in contrast, defines a metamodel (node types and templates etc.) and then based on that metamodel people can define concrete types of elements for concrete models. If you look at the base type definitions we are working on, this lead to something more Heat-like where people use those base types (that every implementation must support) to define concrete templates. Still, the TOSCA "language" gives you the freedom to define your own types.

At a second glance, Heat is not that different. You also have your
"metamodel": you talk about resources, and there is a generic python glass from which all resources derive. From that generic glass you then derive all the python plugins that implement concrete types. The resource type plugins in a way correspond to node types in TOSCA, while the resources in a HOT template correspond to node templates.

The new software orchestration item in Heat even allows to define new building blocks for pieces of software without writing python code. That is also in line with TOSCA, since we want to allow people to define their own "software" node types just providing the scripts or chef recipes or whatever, but not have to write orchestration engine plugin code.

There are more details I could talk about, but I hope what I wrote so far helps to understand the relation (well, at least the way I see it).

>
> Matt also mentioned that Heat doesn't attempt to support an "instance 
> model". If I understand the terminology correctly, this is a 
> straightforward misunderstanding. Heat is not a fire-and-forget 
> service for merely _launching_ cloud applications; it maintains a 
> record of the template and the resources it has created (a "stack" in 
> Heat
> terminology) and orchestrates modifications to the template over time.
> The OpenStack Orchestration mission statement is to manage the entire 
> lifecycle of the application, and this actually works pretty well today.

Fully, agree. Heat has an instance model and Heat does management of deployed applications. I think over time (after having the initial base alignment figured out), this will become very important. TOSCA does not define an instance model, we only define a template "language". Where an instance model becomes important (besides doing declarative updates to an instance), is when start talking about "plan" in TOSCA. As you might know, a service template in TOSCA defines a topology template (that's what we focused on so far) and can optionally have associated management workflows (we call them "plans"). This is basically for all kind of orchestration that cannot be expressed in a topology model, but that is still associated with a topology. For executing those plan, we will need a way for tasks in a plan to access instance data. So here a clean topology model will be important. It will be interesting to see how the Heat stack model fits there.
... BTW, such workflow discussion came up several times in the OpenStack community as well.

>
> The question arose (I think from Frank?) of whether you would be able 
> to move an existing application from one cloud to another. This is a 
> good question, but in my view it does not depend on a bijective 
> mapping. Just as you can't take a running application on OpenStack and 
> relaunch it on another (or the same) OpenStack cloud using Heat 
> without first having a Heat template for it, nor would you be able to do the same for TOSCA.
> Users will have to define their application at the level of generality 
> they want (at TOSCA level - use a TOSCA template; at Heat level - use 
> a HOT template).
>
> By "can't" here, I mean "impossible in theory" (to reverse-engineer a 
> template from a running application). In practice you could probably 
> implement some pretty decent heuristics, but I would prefer not to go 
> down that path in Heat.

IMO, looking at migration of already deployed instances would be a future step. Right now when we talk about portability it is more concerned with being able to deploy one and the same model to multiple platforms.

>
> An interesting related feature that is being implemented in Heat as we 
> speak is stack abandon/adopt. When Heat abandons a stack, it will 
> delete its "instance model" (so the stack is no longer managed by 
> Heat) but output a representation that can be used to re-adopt it again later.
> This provides a path by which users could, in theory, retrospectively 
> write a template for some running application and place it under 
> Heat's management. (In practice I think this would be error-prone if 
> done manually, but it does provide the hook needed for some external 
> tool to implement the heuristics mentioned above.)
>

Definitely some interesting thoughts, but probably (at least IMO) would bust the scope of the current work.

>
> All of this brings me to one idea of where the distinction between HOT 
> and TOSCA could lie. Heat, as it stands, has a very concrete mapping 
> between the template and the stack that is produced from it. I see 
> TOSCA as more constraints-based, where the template describes the set 
> of possible solutions. So one way to look at this would be that a 
> TOSCA engine is a constraints solver that produces a concrete model of 
> the final result, expressed in HOT. From a debugging perspective I 
> like the idea of having an intermediate language that describes 
> exactly what you should get, in addition to the tremendous value 
> provided by a layer that expresses only in general terms what you 
> need. In the very short term, it is probably inevitable that any 
> integration between Heat and TOSCA will take this form, simply due to 
> current limitations in Heat. In the long term I want to emphasize that 
> this is just an idea I have been floating, and is very much open for discussion.

I think that idea of TOSCA being "a more portable" model (because more abstract and loosely bound to details) and HOT being a more concrete model that can be spit out as an intermediate step when deploying a TOSCA model is interesting. It needs some more thought, of course, but could be a viable option.
Another option could be, that a subset of TOSCA can be represented in HOT
1:1 (or maybe in the fuuture that subset _is_ HOT/TOSCA YAML subset). Maybe parts of a TOSCA model could be expressed as a set of smaller but composable HOT models. And then the more abstract, loose binding concepts in TOSCA are a mechanism to declaratively bind the smaller models into a final, deployable model. ... also just a thought on my end so far.

>
> If anyone has further questions about Heat, you are more than welcome 
> to ask them either here or on the openstack-dev mailing list (put "[heat]"
> in the Subject line). I'll be sticking around to try to further my 
> TOSCA education :)

Great! Always feel free to ping me or mail the TC list if you have questions.

Greetings,
Thomas

>
> cheers,
> Zane.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]