Re: [tosca] Groups - TOSCA-Simple-Profile-YAML-v1.3-wd01-rev06-draft.doc

Hi,

Please find my comments inline.

From: Chris Lauwers <lauwers@ubicity.com>
Date: Monday, 3 September 2018 at 22:49
To: Calin Curescu <calin.curescu@ericsson.com>, "NOSHPITZ, CLAUDE" <cn5542@att.com>, Matt Rutkowski <mrutkows@us.ibm.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: RE: [tosca] Groups - TOSCA-Simple-Profile-YAML-v1.3-wd01-rev06-draft.docx uploaded

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:

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.

Right, it says âBy default, an exported Capability should allow at least one relationship to be formed with it with a maximum of UNBOUNDED relationshipsâ. I have an issue with âallowâ, needs to be replaced with require. I would formulate it like: âThe optional range of relationship occurrences for the capability. The minimum specifies the number of relationships that are required to be formed. An orchestrator should strive to fulfill the minimum occurrences during matching if possible (note that this can only be assessed after establishing the instance model and all requirements targeting this capability have been processed). The maximum specifies the maximum allowed number of relationships.â

I also donât agree that by default the minimum should be 1. It should be 0 (i.e. a particular node implementing the capability might not be chosen as target, or might be a target for a different capability). Most nodes implement several capabilities and to require by default to be a target for all of them is not the common case imho.

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.

Ok. (Nevertheless, while reading on group attributes and interfaces I had a stray thought that they could act as a way to group instances from a multiple instance specifications).

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:

I forgot to mention above that this is in the context of requirement mapping in substitution mappings. I.e. while is ok to do capabilities assignment in the mapping (i.e. I just say that the whole template fulfills this capability, and pick some values for the properties and attributes), the requirement assignment in the context of substitution mapping makes no sense. Moreover requirements have no properties or attributes anyway, so there is nothing to assign anyway. I think the section 3.8.10.1 was copied from 3.8.9.1 (i.e. the capabilities counterpart), but itâs just wrong.

Regarding the assignment in the node template that you mention below, I have sent my reply in the other thread.

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

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

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.

Well, each relationship has only one TARGET, but a requirement (with a symbolic name) can specify to have several occurrences which means several relationships for that symbolic name. Thus it can have more TARGETS (which I think was the meaning of having this keyword).

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.

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

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
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.

Hm, I think this is the same as matching directly from type, i.e. should it be allowed to create a new node of a type just for the purpose of matching it?

NO: then how do I solve the following common situation: if I have a database available, use it; otherwise created a new one.
YES: then we should use extra keynames to specify when this is allowed and when not.

Once we solve this, I think substitution matching should behave exactly as matching from type.

The previous 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?

I think we could introduce indexes in the get_property like functions, just after the node or requirement symbolic name. This will not be ambiguous since this is a number and cannot be confuse with a property, requirement, capability, etc. which are string literals.

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

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

No idea

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.

Regarding the wait, as far as I could imagine from reading the specification, it will not wait. This is just an extra guard to not apply it to unsuitable targets.

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.

Ok.

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

tosca message