From: Tal Liron <tliron@redhat.com>
Sent: Tuesday, February 15, 2022 10:57 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Orchestration directives for requirements
Terminology, again.
Sorry, but this is not an issue of terminology. There is a fundamental difference between fulfilling requirements using node representations vs. fulfilling requirements using node templates.
Sure, it would be fulfilled by a node representation. But if we are dealing with the scope of our design then the source of those node representations is our node templates, nowhere else. This is fully reliable and fully deterministic.
We can thus validate the design before creating node representations.
Again, this is incorrect. The TOSCA spec clearly states that requirements can be fulfilled using nodes created using templates other than the topology template that includes the node template with the âdangling requirementâ.
Please see Section 2.9. In fact, Section 2.9.1 has an explicit example of this where a host requirement must be fulfilled using an âexternally-createdâ Compute node. It includes the following text in Section 2.9.1
In the example above, the
mysql component contains a
host requirement for a node of type
Compute which it inherits from its parent DBMS node type definition; however, there is no declaration or reference to any node template of type
Compute. Instead, the
mysql node template augments the abstract âhostâ
requirement with a node_filter which contains additional selection criteria (in the form of property constraints that the provider must use when selecting
or allocating a host Compute node.
Letâs please stop trying to remove functionality from the language that has been in there since v1.0. It has been very clear from the beginning that the purpose of requirements and capabilities is to allow composition
across service templates. Again, the spec states this explicitly in Section 2.9:
TOSCA supports two methods for template authors to express requirements for an abstract node within a TOSCA service template.
1.
Using a target node_filter: where a node template can describe a requirement (relationship) for another node without including it in the topology. Instead, the
node provides a node_filter to describe the target node type along with its capabilities and property constrains
2.
Using an abstract node template: that describes the abstract nodeâs type along with its property constraints and any requirements and capabilities it also exports.
This first method you have already seen in examples from previous chapters where the Compute node is abstract and selectable by the TOSCA Orchestrator using the supplied Container and
OperatingSystem capabilities property constraints.
These approaches allow architects and developers to create TOSCA service templates that are composable and can be reused by allowing flexible matching of one templateâs requirements to anotherâs
capabilities. Examples of both these approaches are shown below.
I am allowing for a reduction in that strict determinism, but I am asking that it be done explicitly, via a keyname. Again, please let's not sacrifice TOCSA's Day 0 strict validation power for Day 1 flexibility. It's possible to have both
by letting the user make an explicit choice.
You continue to say this, and I have asked repeatedly without any answer: what exactly do you think cannot be validated in a design if you allow âdangling requirementsâ as per the 1.3 specification?
Thanks,
Chris
I think youâre making an incorrect assumption that requirements are fulfilled using node templates (rather than node representations). You might be able to do this in special cases
where you donât have node filters and there is no variability in the template, but that is a special case only (and not very useful in practive). In general, if you donât explicitly assign a target in a requirement assignment, then the only time you can reliable
assign that node is at deployment time using node representations.
We need to get agreement on this aspect of the operational model first before we can discuss any more grammar proposals.