RE: Differentiating TOSCA from HEAT

["Bruun, Peter Michael (CMS RnD Orchestration)" <peter-michael.bruun@hpe.com>]

As I understand it, due to Policies, the lack of normative Artifact types (there is no conformance requirement to support any specific type of Artifact) and the fact that there are no normative relationship types, interoperability can only be achieved within a Profile, not across profiles.

 

According to our new Charter point 4.2 Profiles are non-normative. So within the scope of 4.2 we can develop example templates, profiles and related artifacts ââfor testing â interoperability between multiple TOSCA implementations.â

 

Peter

 

From: Chris Lauwers [mailto:lauwers@ubicity.com]
Sent: 10. januar 2022 22:48
To: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>; Tal Liron <tliron@redhat.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: Differentiating TOSCA from HEAT

 

Basically, I find the semantics of TOSCA very loosely defined. Yes, there are the things you mention, but there is a lot of room for interpretation. If you give the same TOSCA definition to your orchestrator, to one of Talâs and to mine, the result would not be expected to be the same, would it?

 

As I remember our discussions over the past year, we have explicitly avoided any such strong portability requirements for TOSCA. This is fine â it is a deliberate decision, and it is ok. We just need to distinguish between the specific ways that each of us interprets and strengthens TOSCA in our implementations and TOSCA itself.

 

Perhaps my memory is failing me (or my biases are playing tricks on my 😊 ) but my recollection is that with the exception of Tal, the team very much wanted to make TOSCA sufficiently well-specified to allow exactly this type of portability (i.e. the same service template would result in the same behavior on different orchestrators that fully implement the language).

 

Chris