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,

thanks for kicking off this important discussion :-D

I do agree with you that Heat supports modeling. The language you offer for that purpose is based on the types/classes (compute, storage,…) that can be managed by OpenStack today. The upside of your approach is that applications can be modeled without having to define separate types. The downside is that such a model is tight to OpenStack. 

In TOSCA we went a different way. We allow (more precise: we require) that you can define your own types/classes of nodes (and relations) that make up your cloud application.  The upside of this approach is that TOSCA is independent of any specific cloud environment (AWS, OpenStack, e.g.) and also independent of the Cloud service model (IaaS, PaaS, SaaS) and the deployment model (private, hybrid,…). The downside is that in TOSCA you need to define types in order to model a particular application. To get rid of  (or weaken) this downside we are about to standardize what we call "based types", i.e. types that are needed for a broad class of applications often brought to a Cloud environment. 

An „instance model“ is a complete representation of the running (deployed) application. TOSCA does not support this today. We do have a draft specification of an API that allows you to retrieve information about a running application. But you can only retrieve information about individual node/relation instances, not the complete application as a whole. In a nutshell, the term „instance _model_“ is confusing, calling it „instance _representation_“ would be more appropriate. 

The term „lifecycle“ in TOSCA is not restricted to going from initial deployment, over some sort of automatic elasticity management to final decommissioning: TOSCA attempts to support any kind of (custom) management action (like backup, restore, user authorization, license management etc) related to the application as a whole or of its individual pieces. This is achieve by means of „plans“, i.e. processes/workflows realizing these management actions. But the focus of TOSCA 1.0 has been on deployment and decommissioning, plans are included in the spec but require more detailed work (like the API mentioned above). I am not sure what Heat’s definition of „lifecycle“ is; it would be nice if you would explain this. 

"Moving an existing application from one cloud to another“ means (at least in my view) the following: if you have a complete model (in TOSCA terms a CSAR including the topology template and all artifacts) available in environment A, you can deploy the same application in environment B in case the latter understands TOSCA - and that’s exactly the purpose of having a standard in this area. But moving a _running_ application from environment A to environment B (without interrupt, moving also its data etc), i.e. some sort of „life migration" is something that is far, far out in the future (in the sense of „not during my lifetime ;-)). I think we are fully in sync on this.

Comment 1:  I don’t understand the relation to „bijectivity“ in this context, at least I didn’t bring it up (I hope ;-)). 

Comment 2: It is possible to discover the topology of an already deployed application and turn it into a CSAR. As your say, this does require heuristics in the discovery algorithm as well as type specific knowledge in terms of node type specific plug-ins. This CSAR can then be deployed in another environment. In this (!) sense, a running application can be moved without having users to specify a template. 

Heat abandon/adopt is very interesting. Similar functions can be offered by a TOSCA container by providing the same functionality but based on TOSCA models. The functionality itself is out of the scope of TOSCA as a standard. 

Your idea of TOSCA as a „constraints solver“ for cloud application models is quite nice :-)  It refers to an exploitation of TOSCA that makes use of requirements and capabilities. In this case, a TOSCA engine will substitute requirements specified by a node template by subtrees of a topology to be deployed. In that way, it will compute a concrete model, i.e. a model that has no longer „dangling“ requirements but consists of actually wired node templates (although an implementation may not compute a complete model but „just“ deploy nodes that specify requirements on available satisfying other nodes with transparent complex substructure). Today, the computed model will be a TOSCA model. But other renderings are possible - see next.

The fundamental technical issue we want to solve by the TOSCA Simple Profile (at least from my point of view) is ensuring a „straightforward“ mapping of a subset of TOSCA to languages of specific environments like OpenStack. Such languages are often simpler than TOSCA, e.g. they don’t support relationship types etc, or they support easy to use ways to pass input and output data. Both, simplifications as well as missing language features will be added to TOSCA 1.1 and a corresponding subsetting will then result in the Simple Profile. In addition, a YAML rendering will be supported for communities that don’t require (or like) XML renderings. 

Having said that, any TOSCA model making use of the language elements of the Simple Profile should be „close“ to a HOT model (and other models like e.g. a Cloud Foundry Manifest). „Close“ should be read „isomorphic“ and ideally the isomorphism would be established by renaming keywords of TOSCA and HOT :-)

I am looking forward to your comments and responses to continue this important discussion :-D

Gruss/Regards,
Frank




Am 22.02.2014 um 01:45 schrieb Zane Bitter <zbitter@redhat.com>:

> 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.
> 
> 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.
> 
> 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.
> 
> 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.)
> 
> 
> 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.
> 
> 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 :)
> 
> 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]