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,

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
>



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