RE: [tosca] Groups - TOSCA Architectures and Language impact uploaded

[Chris Lauwers <lauwers@ubicity.com>]

We could do that, but then (as you said) weâre going back to associating semantics with the profile/type system, rather than with the grammar.

 

Chris

 

From: Tal Liron <tliron@redhat.com>
Sent: Friday, December 4, 2020 10:38 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>; Calin Curescu <calin.curescu@ericsson.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA Architectures and Language impact uploaded

 

On Fri, Dec 4, 2020 at 12:19 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Since we want to have it both ways, it seems to me that the only option we have is to categorize features in two sets:

 

• Features that are required for all implementations.
• Features that are only required for âpure TOSCA orchestratorâ implementations.

The architecture discussions weâve been having are the foundation based on which we can start categorizing functionality.

 

Agreed! And I think we are making progress.

 

But I remain convinced that it is possible to provide "pure TOSCA" solutions without encumbering the grammar.

 

One thought I had -- perhaps there can be a standard profile called "orchestration", which provides all these common "pure" features. Things like workflows and lifecycles and standard ways to specify requirements as templates. It might sound like I am going back to the idea of an included Simple Profile that I fought so hard to remove. :) But actually the idea is to reimagine such a profile -- instead of standardizing on a non-existent cloud we can standardize on actually existing "pure" orchestrators, like Ubicity, Cloudify, etc. And of course it would be optional, as you would need to explicitly import it. But you could assume it exists to be imported in all TOSCA 2.0 implementations.