I very much like the direction in which Peterâs presentation has taken us. I think we can continue to fine-tune the various stages in the architectural evolution. In fact, Iâd like to revisit the first stage (the âminimalâ architecture
with an external orchestrator). Iâm attaching a slide that makes a couple of modifications:
-
The âsemantic modelâ (AKA the instance model) in Peterâs diagram is actually what comes out of the TOSCA functional blocks, not what goes in. What goes in is still a âtemplateâ. I separated the âsemantic modelâ block in Peterâs diagram into a âsemantic templateâ
and an âinstance modelâ.
-
If that is the correct interpretation, then I believe the âservice inputsâ go directly into the âinstantiationâ block, since the âinstantiationâ function is responsible for turning a service template into a service instance model (by providing it with the necessary
input values)
-
If an external orchestrator is used, then I believe there is no use for TOSCA Interface Operations. Instead, the actual ârealizationâ of the instance model will get delegated directly to the external orchestrator (possibly with the necessary translations to
make sure the instance model is encoded in a format that the external orchestrator understands).
Please letâs continue to iterate over email.
Thanks,
Chris
From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Chris Lauwers
Sent: Tuesday, November 17, 2020 11:51 AM
To: Calin Curescu <calin.curescu@ericsson.com>; Peter Bruun <pmb@hpe.com>
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Groups - TOSCA Architectures and Language impact uploaded
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
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
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
|