RE: [tosca] Groups - TOSCA-Simple-Profile-YAML-v1.3-wd01-rev06-draft.docx uploaded

[Chris Lauwers <lauwers@ubicity.com>]

Hi Calin, comments in-line:

 

From: Calin Curescu <calin.curescu@ericsson.com>
Sent: Thursday, August 23, 2018 4:01 AM
To: Chris Lauwers <lauwers@ubicity.com>; NOSHPITZ, CLAUDE <cn5542@att.com>; Matt Rutkowski <mrutkows@us.ibm.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA-Simple-Profile-YAML-v1.3-wd01-rev06-draft.docx uploaded

 

Hi,

 

While doing the âlistâ to âmapâ changes I managed to look through some sections and paragraphs that contained the word âlistâ. I also came to the following:

1. Inconsistencies that need to be addressed:
   1. The occurrences definition in the capability definition (section 3.7.2) is nonsensical. We should change it to mean  dangling unmatched capability, that should not be allowed once the node with such a capability is matched and introduced in the instance model.

Iâm not sure what your concern is here.  The âDescriptionâ in table 2.7.2.1 could be improved, but in general this seems correct to me: the occurrences keyname specifies how many times this capability can be used as the target for a requirement in some other node. If a capability is already used, that doesnât mean it canât be used again for some other requirement later.

2. In the definition of group type, in section 3.7.11.2 attributes are not in grammar example, capabilities are not in the following legend

We need to revisit the definition of groups. Groups should just be a short-cut to specify a collection of nodes for purposes of policies etc. Groups donât have a lifecycle of their own. The fact that we introduced Interfaces on groups is a mistake. This needs to get corrected. It also makes no sense for groups to have properties, attributes, capabilities, and requirements. All those need to be removed.

3. Requirement assignment is wrong and should not be allowed. The whole section 3.8.10 needs to be reviewed. See comments in document.

Agreed. We need to get on the same page. I sent out some comments about this yesterday. Iâm including them again here:

 

There are really two completely different use cases for requirement assignments:

 

1. The first use case is the straightforward one, where the requirement assignment specifies the specific capability (and the node template that contains that capability) that fulfills the requirement. The requirement assignment typically also specifies the relationship template (either in-line or by reference) that is used to âcreateâ the relationship (where that relationship template can contain properties).
2. The second use case is the âdangling requirementâ use case. In this scenario, the requirement assignment doesnât specify how the requirement is fulfilled, but rather it further narrows (using node filters) the set of capabilities (and containing nodes) that can be used to fulfill the requirement. Presumably, the orchestrator will use the node filter to construct a query to retrieve candidate capabilities (and nodes) from its inventory. This is the scenario where the requirement assignment can âchangeâ the node type, capability type, and relationship type that were specified in the requirement definition (in the node type), AS LONG AS THOSE TYPES ARE DERIVED FROM THE CORRESPONDING TYPES SPECIFIED IN THE REQUIREMENT DEFINITION. This ârefinementâ scenario is similar to the refinement scenario for data types that we have been discussing over the last two weeks.

 

4. The context of several TARGETS should be of the requirement, not of the relationship (each relationship has only one TARGET), see comment in document. See section 4.2.1. Same for SOURCES and capability instead of resource. See section 4.2.1.

We should talk about this. In my opinion, there is no difference between a relationship and a requirement. A relationship is a âfullfilledâ requirement, whereas a requirement is a relationship that hasnât been established yet. Either way, they specify the same concept. Thatâs also (in my opinion) why we donât have requirement types or why requirements themselves donât have propeties: the type of the requirement is really the relationship type, and the properties of the relationship are (conceptually) also the properties of the requirement. In my instance model, i use the same object for requirements and relationships.

5. The usage of unordered list in sections 6.2.1 and 6.2.2 proposes a YAML wrong syntax. We should correct.

Yes. We also may want to revisit whether unordered lists are the best choice here.

2. I think also that the presentation of substitution_mappings is lacking:
   1. To improve the definition of the different mappings in the substitution_mappings description

                                          i.    section: 3.9.2.7 and 3.8.12

2. To specify that the operation outputs mappings from section 3.6.17 are constrained as node name for the keyword SELF and as relationship name for the keyword SELF, SOURCE, TARGET
3. Provide a hyperlink to attribute mappings in section 3.6.17.1, and 3.6.18.1.

There is a separate issue with substitution mappings that needs to be addressed. In order to support substitution, two features are required:

• Matching: find the âbestâ service template that matches the abstract node.
• Mapping: map entities from the abstract node to corresponding entities in the substituting template.

The current syntax confuses/mixes these two issues. Specifically, it abuses the mapping syntax to guide the mapping by setting hardcoded values in the mappings. I would like to see an enhancement instead that introduces a separate âmatchingâ section (similar to node filters, for example) that drives the matching process. This would simplify the mapping syntax as well.

3. The previus is in addition to the mail thread on how to specify substitution mappings for requirements with several occurrences, where we would like to used different nodes in the substitution template for different subsets/each of the occurrences.

Yes, there is a general need to enhance the âtopology navigationâ syntax to allow drilling down into specific instances of requirements (and possibly nodes once we support node templates that support multiple instances). Xpath for TOSCA?

4. Regarding the document form, I think:
   1. we should replace some cross-references with hyperlinks in several examples.

                                          i.    the hyperlinks are clearly marked (blue underline) that they are clickable. This should be used when pointing to definitions.

Yes

                                         ii.    cross-references are indistinguishable from normal text, this should be used when referring to section numbers, as they will be automatically updated

Yes

2. question: why do we use bookmarks and the section headings for the hyperlinks in the text?

No idea

5. Some additional questions:
   1. If an imperative workflow step evaluation filter is false, will the on_success still be triggered, or the step will silently be discarded. What will happen with the next step that is waiting for this to finish?

Good question. Does the orchestrator wait for the condition to become true somehow? How would this happen? The same question holds for the âpre-conditionâ on the Workflow as a whole.

2. How can the parser differentiate between a key in a property of a complex type assignment and an intrinsic function to be evaluated?

I think we need to clearly specify precedence rules: In my opinion, we should always interpret these as names of the intrinsic functions, which means that you cannot use a key in a complex type that is the same as the name of an intrinsic function.

 

BR,

/Calin

 

 

From: <tosca@lists.oasis-open.org> on behalf of Calin Curescu <calin.curescu@ericsson.com>
Date: Thursday, 23 August 2018 at 12:31
To: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: [tosca] Groups - TOSCA-Simple-Profile-YAML-v1.3-wd01-rev06-draft.docx uploaded

 

Submitter's message
Please find the draft proposal for rev06 of v1.3. The main change is to replace "list" with "map", and "sequenced list" with "list", to avoid confusion and conform to proper YAML denomination. See more detail in the document revision history.
-- Dr. Calin Curescu

Document Name: TOSCA-Simple-Profile-YAML-v1.3-wd01-rev06-draft.docx

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Dr. Calin Curescu
Group: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder: Working Documents
Date submitted: 2018-08-23 03:29:29