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: Differentiating TOSCA from HEAT


On Tue, Jan 4, 2022 at 8:33 AM Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> wrote:
In the previous meeting you mentioned some bad experience with HEAT and how we want to make sure TOSCA is perceived as superior.

It's a useful comparison, but importantly TOSCA is not so clearly superior in every aspect. The fully-declarative approach has linguistic disadvantages.

By the way, "Heat" is the orchestration module, "HOT" is the language, though this distinction isn't always very meaningful. It becomes meaningful in the Tacker project, which intends to be a TOSCA frontend for Heat (behind the scenes it translates to HOT, as far as I remember). By the way, Tacker's "problem", as I see it, is not in its use of TOSCA, but in its use of the Simple Profile. The Simple Profile means that Tacker can do much less than HOT. But there's no reason why Tacker can't model all OpenStack resources in TOSCA. I have an example of this. Also note that Puccini can compile HOT into Clout, though obviously HOT is missing many features over TOSCA.

Â1.ÂÂÂÂÂÂ HEAT has no custom nodetypes and no inheritance â HEAT only supports a closed set of built-in OpenStack service types (Nova, Neutron etc) are supported.

Well, you can, it's just not very easy. But it is powerful. TOSCA is designed to be extensible by using TOSCA itself (that's sometimes how I explain TOSCA to people: the same language is used for both the resources and their schema). For HOT you need to use Python, but once you are in Python you can perform all kinds of validations that are impossible to do in TOSCA.

2.ÂÂÂÂÂÂ HEAT has nothing like requirements-capabilities or other abstraction mechanisms.

This is essentially true. TOSCA capabilities allow for a kind of composition (I often call a TOSCA node an "assemblage" of capabilities). In HOT these sub-components are all separate resources. The assemblage is often implied by using the get_resource function.

3.ÂÂÂÂÂÂ HEAT has no concept of artifacts since all functionality is hard-coded in OpenStack.

Well, artifacts are not their own types (and there is no packaging format, like CSAR), but they are supported in a few ways:

1. The get_file function lets you insert artifacts anywhere in HOT. This is actually more flexible, in some ways, to TOCA's get_artifact function.
2. Some OpenStack components support artifacts and these are specifically modeled as resource types. Examples: Glance WebImage, Barbican Secret, Heat CloudConfig, etc.

(By the way, HOT has more intrinsic functions than TOSCA, so it "wins" in this respect.)

4.ÂÂÂÂÂÂ HEAT has no concept of a service graph. There are of course connections between network ports and server interfaces, but these are not formalized as a real Ârelationship-based graph structure

I wouldn't say that it has no such concept, just that it has a very weak one. There is only one kind of relationship in HOT and that's "dependency", which is implicitly created via calls to functions such as get_resource and get_attr. It's possible to extract this graph from the HOT parser.

I find "dependency" relationships to be the least interesting. They are important for one and only purpose: to automatically create a "deploy" workflow for non-declarative platforms. TOSCA's power is in introducing typed relationships, where each type implies its own semantic graph. One obvious use is networking, but we see graphs everywhere in the cloud: clustering, redundancy hierarchies, data streaming, service meshes, etc.

5.ÂÂÂÂÂÂ HEAT assumes everything is managed by OpenStack â the HEAT model does not extend to containers and other management systems such as K8

Well, this is true in the sense that all supported modules are part of the OpenStack project. But the point is that OpenStack is modular, and every OpenStack module represents its own management system. For example, Neutron is very different from Nova. And then you have something like Magnum for containers, which is again different from Nova. And it's definitely possible to create a custom module, which supports HOT, but is not part of the OpenStack family of modules.

6.ÂÂÂÂÂÂ HEAT has no concept of events and closed loop management of services

Yes, but I would argue that TOSCA doesn't, either. At least not yet. :)

You can probably manage event streams as relationship types. But doing so is in no way integrated with TOSCA operations/notifications.

7.ÂÂÂÂÂÂ The lifecycle of HEAT objects is a âprimitiveâ exists/not-exists model â this cannot be extended

So, if you recall from above, the dependency graph is used to generate a deployment workflow, which is not entirely unsophisticated LCM. There is, at least, an idea of when in time the object exists or does not exist.

But also you can plug in your own custom Mistral Workflow.

Without saying anything bad about Mistral, I'll mention that most users probably use an external workflow engine to do their LCM work, something like Ansible.

8.ÂÂÂÂÂÂ HEAT has poor error handling. If a request fails, there is no way to clean up or retry a half-created service (Hmm. How do we do that with TOSCA?)

Yes, Heat is also slow and painful and does not scale well. But that's not the fault of the HOT language. I mostly blame the traditional phase-by-phase paradigm baked into OpenStack for this. I think it's important for TOSCA to support this paradigm because many systems look like this, but I can't see how TOSCA can fix the problem of "half-created services" (indeterminate states). It's not a language challenge but an architectural challenge.

The solution I propose is simply "don't do this", or rather "don't assume that you can succeed in doing LCM in the cloud". In fully-declarative approaches there is no concept of order and time and instead you take for granted that state is emergent (and to an extent ephemeral). TOSCA doesn't have to do anything special to support this paradigm because, again, it's a matter of "don't do this". If you're not modeling any kind of workflow then the feature is just not there. So TOSCA lends itself quite easily to a fully-declarative approach. Then again, so does HOT. The problem is not HOT the language but Heat the orchestration module.

ÂPlease add moreâ


Hm, here's what I can think of are the main advantages of TOSCA:

1. TOSCA is a standard with wide industry support. HOT isn't. The standard also includes a packaging format (CSAR).

2. The fact that TOSCA is models + schema in one language is a major advantage over HOT. Indeed TOSCA's power of validation is way, way beyond anything HOT can do. This extends to data types, which are fairly rich in TOSCA (but can be richer -- see OpenAPIv3). TOSCA's new-ish support for profiles in 2.0 makes all of this even more powerful, as it allows TOSCA to be used for all kinds of orchestration domains. Indeed, a single service can be described at various levels in just one topology template that imports multiple profiles.

3. TOSCA allows for custom integrations with subsystems via interfaces/operations/notifications.

4. TOSCA has many implementations rather than just one (well, I guess you can use HOT with Puccini...). Each implementation has different approaches to orchestration and integration. So, TOSCA is just more broadly useful than HOT. HOT for the most part limits you to an OpenStack-based environment (though again you can extend it for your own custom subsystems). The loose specification meant that for a while TOSCA implementations diverged quite a lot, but with TOSCA 2.0 we hope to run a tighter ship and increase interoperability.


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