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