RE: Agenda for July 2nd TOSCA Language Ad-Hoc WG meeting

Hi Shitao, Chris, all,

Since the discussions on the important topic of the input handling is taking time, maybe we can progress other topics offline.

For example, this one discussed in ETSI NFV. Thanks, Shitao, for bringing it up. Some thoughts below.

With regards to issue# 2:

Here we are talking about a requirement in the substituting template that is reflected in the substitution mapping. It is obvious that the matching node cannot be indicated in the substituting service template, as this is only known in the top level. I am assuming that option 2 (removing the requirement assignment in the low level service template) should be ok, even if this requirement appears in the substitution mappings, as what it matters is the target node, capability and relationship types of the requirement so that the orchestrator can verify its compatibility with the mapped requirement, and these types have been defined in the node type definition.

Otherwise I would be in favour of allowing an empty requirement assignment in this case:

- virtual_link

With regards to issue #1:

This is more problematic because we are talking about a requirement (virtual_link) that will not be matched by a node under the jurisdiction of the same TOSCA orchestrator. In other words, no node in the service template handled by this TOSCA orchestrator will match the requirement. For example:

a) the virtual_link requirement representing a VnfExtCp will not be matched by any node handled by the VNFM

b) the virtual_link requirement representing a SAP will not be matched by any node handled by the NFVO

This doesn't look as a TOSCA grammar issue (from TOSCA perspective the service template is probably incomplete as we have a requirement with no matching in the service template). We could remove the virtual_link requirement when it is not matched in the service template, but then the substitution mapping indicated in the low level would be incorrect. I am even thinking that we may need a dummy node in the top level template to represent a virtual link that is part of another orchestrator domain and use it to match the virtual_link requirement.

BR,

Arturo

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Lishitao
Sent: Tuesday, July 2, 2019 3:23 PM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: [tosca] RE: Agenda for July 2nd TOSCA Language Ad-Hoc WG meeting

Hi Chris and all

If we still have time, I suggest we add the multiple DF topic into the agenda,

https://www.oasis-open.org/committees/document.php?document_id=65552&wg_abbrev=tosca

this issue came from ETSI NFV, I volunteer to bring it into OASIS TOSCA for discussion.

Thanks.

Regards

shitao

åää: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] äè Chris Lauwers
åéæé: 2019å7æ2æ 11:43
æää: tosca@lists.oasis-open.org
äé: [tosca] Agenda for July 2nd TOSCA Language Ad-Hoc WG meeting

During Tuesdayâs meeting, we will discuss the following:

We will discuss the difference between:

Instantiating a service from a template
Making modifications to a running service

This discussion is motivated by our meetings of the last two weeks that discussed workflows (and specifically how to route input values to workflows).
We will specifically try to address:

How do we âlinkâ input values carried in API calls to the service template
Do we expect a one-to-one relationships between external API calls and workflows?
Which types of âactionsâ taken on a running service result in orchestrator actions other than running workflows (e.g. substitution mapping or requirement fulfillment)

Please join using Zoom at 7:00am Pacific time.

https://zoom.us/j/875426495

Thanks,

Chris

tosca message