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

[Chris Lauwers <lauwers@ubicity.com>]

Hi Arturo,

 

Apologies for not responding earlier:

 

• Yes, issue # 2 seems to just be a clarification of syntax issues. All 3 cases in Shitaoâs proposal are effectively âno-opsâ: they leave requirements (that were previously defined in the type definition) unchanged.
• W.r.t issue # 1, we need to have additional conversations about what the intent is of dangling requirements in TOSCA. As we discussed in Tuesdayâs meeting, my opinion is that dangling requirements should be fulfilled using entities (represented as TOSCA nodes) in an Inventory (rather than using nodes that are created on-demand by a TOSCA orchestrator). Iâll add this discussion to the list of topics to be discussed during our TOSCA Language Meetings.

 

In addition, Shitaoâs examples raise a number of other issues related to substitution mapping (and specifically the mapping of requirements). For example

 

• It seems to me that all mandatory requirements of an abstract node (i.e. requirements with occurrences range greater than 0) must be mapped to a corresponding requirement in the substituting template. If there are mandatory requirements that are not mapped, then that would be a template error.
• As you already stated, if an abstract node has a requirement that has been fulfilled (i.e. the requirement has a relationship to a target node), then that requirement cannot be mapped to a requirement in a substituting template that also has been fulfilled. Or, said a different way, fulfilled requirements in an abstract node can only be mapped to dangling requirements in a substituting template.
• Iâm not sure about the opposite scenario: what if an abstract node has a dangling requirement, but that dangling requirement is mapped to a fulfilled requirement in a substituting template. Is that legal?
• Since a substituting template must be a valid (deployable) template in its own right, it is conceivable that dangling requirements in the substituting template have node filters associated with them. How do we handle the case where a requirement in an abstract node maps to a requirement with a node filter? Do we need to check that a target node that fulfills the requirement of the abstract node âsatisfiesâ the constraints specified by the node filter in the substituting template?
• Can we map a dangling requirement in an abstract node to a dangling requirement in a substituting template?
• If so, what if both the dangling requirement in the abstract node and the dangling requirement in the substituting template have node filters? Do the node filters need to be compatible? If not, which one is used? Do we combine the filters?

 

Lots of issues to be addressed 😊

 

Thanks,

 

Chris

 

From: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>
Sent: Wednesday, July 03, 2019 12:59 AM
To: Lishitao <lishitao@huawei.com>; Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: 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