Re: [tosca] Orchestration directives for requirements

On Tue, Feb 15, 2022 at 2:57 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Your approach is almost identical to the âscopeâ keyword Calin proposed several weeks ago.

It is similar. Calin deserves credit. :) Slightly different focus in that I'm concerned with what it means for when things can be validated: at the moment of deployment or prior. What I am proposing here is that any directive would mean "postpone", even if one of the directives is "internal".

Yes, if a requirement is dangling, you cannot validate at design time that it is guaranteed to exist. But that is not a âdesign validationâ issue. That is a runtime resource availability issue, which you can never handle in a design. No matter how many resources you specify in a design, if theyâre not available (or cannot be created) at runtime because of resource availability issues, youâll end up with a runtime failure. Again, this has nothing to do with design validation.

Of course. A valid design does not guarantee it can be deployed. But a valid design is still a very valuable thing. The more you can do in Day 0, the better.

2.9.2 doesn't have this compromise between "design time" and "runtime". You specify a node template explicitly and give it a "select" directive. Your design will still be complete and valid. There's indeed no way to guarantee that there won't be a runtime error.

I completely agree that everything that needs to be created should be specified explicitly. The only disagreement we have is that you think everything should be in the same template.

I proposed an "external" directive, despite not liking it. So, yes, we can for 2.9.1. The only thing I ask is that it does not happen automagically. I want to make sure that if a requirement is not using directives then it means that its target can be deterministically determined on Day 0 (prior to deployment). (And, yes, the actual target on Day 1 will be a node representation not a node template. This is just about knowing deterministically in advance what will happen.)

There is nothing wrong with 2.9.2, expect that it is an optimization that handles the specific case where you need requirements from different sources to be fulfilled by the same target node. But as we have discussed before, it has other problems and it doesnât justify removing the core requirements functionality.

Again I suggest we start with 2.9.2 because it has the least amount of problems. But my proposal here, which I think is fairly straightforward, addresses both 2.9.1 and 2.9.2 and attempts to explain "occurrences" in relation to them.

tosca message