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

[Chris Lauwers <lauwers@ubicity.com>]

Also, Iâm resending the presentation I used back in April when I presented the Ubicity Orchestrator to the TC. It shows the functional blocks of the TOSCA orchestrator.

 

Thanks,

 

Chris

 

 

From: Chris Lauwers <lauwers@ubicity.com>
Sent: Tuesday, November 17, 2020 2:53 PM
To: Chris Lauwers <lauwers@ubicity.com>; 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 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:

 

1. 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â.
2. 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)
3. 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:

 

1. Instantiation
2. Requirement fulfillment
3. Substitution

 

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

 

1. 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)
2. 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

 

Attachment: Ubicity TOSCA Orchestrator 2020 04 22.pptx
Description: Ubicity TOSCA Orchestrator 2020 04 22.pptx