RE: Differentiating TOSCA from HEAT

[Chris Lauwers <lauwers@ubicity.com>]

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