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


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