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.
Thanks,
Chris
From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: Tuesday, February 15, 2022 10:42 AM
To:
tosca@lists.oasis-open.org Subject: [tosca] Orchestration directives for requirements
I'd like to propose a straightforward addition that may allow us to move forward.
The issue at stake is strictness.
The idea is that TOSCA errs on the side of strictness. In this context, by default requirements will need to be fulfilled within the topology. Here is an example of a valid service:
capability_types:
Server: {}
node_types:
App:
requirements:
- host:
capability: Server
Server:
capabilities:
server: Server
topology_template:
node_templates:
app:
type: App
requirements:
- host: {}
server:
type: Server
If we remove the "server" node template then the service will no longer be valid. Validators like Cloudnet and Puccini would emit an error because they cannot find a target:
node_templates:
app:
type: App
requirements:
- host: {} # INVALID!
To change this behavior to be less strict I propose we introduce orchestration directives, similar to those in node templates. When directives are added (one or more) to a requirement then fulfillment would depend on the orchestration environment.
Validators like Cloudnet and Puccini would then not emit an error when a target cannot be found. Example:
node_templates:
app:
type: App
requirements:
- host:
directives: [ optional, external ] # VALID!
When orchestration directives are present it means that errors, if they happen, would be reported at the
moment of the deployment . You can call this a "dangling" requirement if you like that term. I would call it "postponed fulfillment" (postponed to the moment of deployment). To be clear, it doesn't matter if the "server" node template is present or not
when directives are present, it would always be considered valid before deployment, when directives are present.
And that's it. It's simple and explicit and strictness is clear.
We can settle on a list of conventional orchestration directives while allowing users to introduce their own. Examples:
"optional": If the requirement cannot be fulfilled at the moment of deployment then there will be
no error. (Of course, errors might happen while trying to fulfil the requirements, e.g. an inventory is down.) In other words it's a "nice to have".
"external": Search for targets from outside of this service.
"internal": Search for targets inside the service (e.g. the "server" node template, if present).
You would be able to set both "internal" and "external" together if you want to support both possibilities. Since directives are ordered, we can decide that the search order depends on the order you write the values, e.g. [ external, internal
] means: try external targets first, and if not found then try internal ones.
We would also include the "directives" keyname in requirement definitions. And we would need to think about refinement rules. (Are we only allowed to add directives, or also remove them when refining?)
You can assign each requirement multiple times and use different directives and filters for each.
IMPLICATIONS FOR "OCCURRENCES"
I'm happy to redact my previous proposal about "occurrences" being a grammatical tool. Chris called my approach "off left field". To be honest, I am in favor of removing this keyname entirely and was trying to salvage something of coherent
value from it. But I'm willing to let go of my proposal as long as the counter proposal is clearly defined. I am willing to agree, as Chris desires, that these numbers would
only apply to counting relationships formed at the moment of deployment . So this means it has
nothing to do with counting assignments and it is not a grammatical tool.
With that in mind, how would processing and validation work in tools like Cloudnet and Puccini? They don't deploy, but there is still some validation work they could do. (Puccini also forwards these numbers to an orchestrator that would
do the deployment.)
First, they can of course make sure that the numbers fit within the refinement rules.
Second, they can check if totals would be guaranteed to fail. It would be a bit complex, because it would involve counting non-optional and optional assignments separately. If the non-optional total is greater than the upper bound
of the range, then that is guaranteed to fail. They can also check if the sum of both optional and non-optional totals doesn't meet the lower bound. Again, it's a situation that is
guaranteed to fail. Of course, even if a design is not guaranteed to fail it can still fail if not enough targets are found at the moment of deployment. Cloudnet and Puccini cannot help with that. If you decide to use orchestration directives,
you need to understand that important implication.
Third, they can automatically and implicitly add in missing assignments. The rule, considering this new understanding, would be very straightforward and does not involve counting at all, and it falls in line with what Chris suggested, that
is if and only if the user does not assign the requirement then it would be automatically assigned
once for them, using the numbers and directives declared in the requirement definition. Example:
node_types:
App:
requirements:
- host:
capability: Server
directives: [ optional ]
occurrences: [ 2, 5 ]
topology_template:
node_templates:
app:
type: App
Because we did not assign the "host" requirement at all, then an implicit one will be added, equivalent to this:
node_templates:
app:
type: App
requirements:
- host:
capability: Server
directives: [ optional ]
occurrences: 2
As you can see, the "occurrences" numbers have nothing to do with counting assignments. We've added exactly one, essentially a copy-paste from the definition, where "occurrences" for the node template got the lower bound of the "count"
range in the definition. (There is no need for that confusing upper bound in the node template. The "optional" directive covers the "nice to have" feature.)
Let's also please change the keyname to "count", because "occurrences" in English means "an incident or event", which is very confusing in this context. So:
node_types:
App:
requirements:
- host:
capability: Server
directives: [ optional ]
count: [ 2, 5 ]
topology_template:
node_templates:
app:
type: App
requirements:
- host:
capability: Server
directives: [ optional ]
count: 2