OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Submitter's message For discussion, I have started from Chris' minimal architecture and elaborated on more complex architectures and hinted what they may mean for the TOSCA language design.
The intention is to disambiguate and clarify why some of us think that some proposed language features are redundant and others believe them to be critical. -- Dr. Peter Bruun Document Name : TOSCA Architectures and Language impact Description For discussion, I have started from Chris' minimal architecture and elaborated on more complex architectures and hinted what they may mean for the TOSCA language design. Download Latest Revision Public Download Link Submitter : Dr. Peter Bruun Group : OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC Folder : Working Documents Date submitted : 2020-11-16 02:46:07

Hi Peter,
 
Very good additive representation. With respect to the TOSCA work, I always assumed that both the TOSCA model catalogue and Instance model inventory are expected for a comprehensive solution.
Regarding the instance export this is a good proposal, as it will:

Spell out the instance model representation Make it easier to save/load/exchange/log instance models
One thing I have not thought of is the direct topology change . We need to understand if this is needed or all the topology changes happen only via input / runtime operation changes.
 
BR/Calin
 

From: <tosca@lists.oasis-open.org> on behalf of Peter Bruun <pmb@hpe.com>
Date: Monday, 16 November 2020 at 11:48
To: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: [tosca] Groups - TOSCA Architectures and Language impact uploaded


 

Submitter's message
For discussion, I have started from Chris' minimal architecture and elaborated on more complex architectures and hinted what they may mean for the TOSCA language design.
The intention is to disambiguate and clarify why some of us think that some proposed language features are redundant and others believe them to be critical.

-- Dr. Peter Bruun




Document Name :

TOSCA Architectures and Language impact





Description
For discussion, I have started from Chris' minimal architecture and
elaborated on more complex architectures and hinted what they may mean for
the TOSCA language design.
Download
Latest Revision
Public
Download Link





Submitter : Dr. Peter Bruun
Group : OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder : Working Documents
Date submitted : 2020-11-16 02:46:07




 

I tend to agree with Calin. In the original minimal architecture we defined 3 functional blocks:
 

Instantiation Requirement fulfillment Substitution
 
Without instance model inventory and TOSCA service catalog , the functionality that can be provided by these functional blocks is severely limited:
 

Without an instance model inventory , the requirement fulfillment function can only consider/select node instances that are created from the same service template as the template
that contains the dangling requirement (which renders the requirement fulfillment feature almost useless) Without a TOSCA service catalog , the substitution function can only consider service templates that are packaged in the same CSAR as the service template that contains the abstract
node(s) that require substitution.
 
I think the minimal architecture diagram is useful for purposes of educating people on how TOSCA works, but I can t see how a TOSCA orchestrator that only implements the minimal architecture will get much use.
 
Thanks,
 
Chris
 
 


From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Calin Curescu
Sent: Tuesday, November 17, 2020 7:00 AM
To: Peter Bruun <pmb@hpe.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA Architectures and Language impact uploaded


 
Hi Peter,
 
Very good additive representation. With respect to the TOSCA work, I always assumed that both the TOSCA model catalogue and Instance model inventory are expected for a comprehensive solution.
Regarding the instance export this is a good proposal, as it will:

Spell out the instance model representation Make it easier to save/load/exchange/log instance models
One thing I have not thought of is the direct topology change . We need to understand if this is needed or all the topology changes happen only via input / runtime operation changes.
 
BR/Calin
 

From: < tosca@lists.oasis-open.org > on behalf of Peter Bruun < pmb@hpe.com >
Date: Monday, 16 November 2020 at 11:48
To: " tosca@lists.oasis-open.org " < tosca@lists.oasis-open.org >
Subject: [tosca] Groups - TOSCA Architectures and Language impact uploaded


 

Submitter's message
For discussion, I have started from Chris' minimal architecture and elaborated on more complex architectures and hinted what they may mean for the TOSCA language design.
The intention is to disambiguate and clarify why some of us think that some proposed language features are redundant and others believe them to be critical.

-- Dr. Peter Bruun




Document Name :

TOSCA Architectures and Language impact







Description
For discussion, I have started from Chris' minimal architecture and
elaborated on more complex architectures and hinted what they may mean for
the TOSCA language design.
Download
Latest Revision
Public
Download Link







Submitter : Dr. Peter Bruun
Group : OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder : Working Documents
Date submitted : 2020-11-16 02:46:07




 

On Tue, Nov 17, 2020 at 1:51 PM Chris Lauwers < lauwers@ubicity.com > wrote: Without instance model inventory and TOSCA service catalog , the functionality that can be provided by these functional blocks is severely limited: I think these are often useful but not absolutely required and indeed there can be twists. Without an instance model inventory , the requirement fulfillment function can only consider/select node instances that are created from the same service template as the template that contains the dangling requirement (which renders the requirement fulfillment feature almost useless) Without a TOSCA service catalog , the substitution function can only consider service templates that are packaged in the same CSAR as the service template that contains the abstract node(s) that require substitution. Of course, as you know I disagree with the "dangling requirement" feature, and in my view these two features are essentially identical for the orchestrator in that they allow for a node to be "provided" from somewhere else. The difference in #2 is a TOSCA grammatical feature, allowing a TOSCA service template to explicitly "provide" a node. My point is that how exactly the orchestrator "provides" is beyond the scope of TOSCA. It could be an inventory, but it doesn't have to be. The orchestrator could simply look for existing resources in the cloud, whether they were created via TOSCA or not, thus the cloud itself becomes the inventory. And of course an orchestrator could also provision such implementations itself on-demand. As for catalogs, it does seem that if a service template does substitution then of course the orchestrator would have to know of it and thus it must be "somewhere". But, again, it doesn't have to be in a catalog. For example, a bunch of CSARs can be provided at once to the orchestrator, to be used just at the moment of the day 1 instantiation, and they do not necessarily have to live in a catalog. My one concern here is that inventories and catalogs involve state and and state management, but there is a lot of room for orchestration that is as stateless and lightweight as possible. I still think the minimal architecture is functionally sufficient for TOSCA orchestration. My second concern is not to scare off potential consumers of TOSCA, who might look at a complex architectural diagram and worry about the amount of effort they would need to put in in order to make use of TOSCA.