I would like to jump in in relation to the capabilities occurrences. I don't think a node template can express the "requirement" that a capability must be used, i.e. if a topology template
contains a node template that has a capability which is not used to match a requirement, I wouldn't consider that as an error, even if the capability definition indicates an occurrences minimum value > 0.
Â
If we read the description of the occurrences key name in the capability definition, it refers to the number of relationships "allowed" to be formed, not "required" to be formed.
I'm inclined to agree. The problem is that the "occurrences" keyword is of type range, so it does have a minimum. I am doing my best to make sense of the spec, even when it doesn't to me. :) So perhaps it should be called "maximumIncomingRelationships" or similar, and be integer, if that's the real intent.
I really wish we can remove this keyword entirely, both in requirements and capabilities. If the intent is to create some sort of limits (upper or lower) for counting design-time relationships, it is unclear what the use case is.
From my experience, most newcomers to TOSCA understand this as relating to runtime relationships. But a design-time relationship is not a runtime relationship. The line is drawn on the graph, but whether this translates to a deployment with one database connection, a pool of twenty round-robin SD-WAN links, a one-to-many directory to install software on all instances of a compute target, or even no runtime resource at all, etc. etc. etc. is beyond what this could do.
The right way to do this, I think, already exists: properties, for both relationship types and capability types. They can be used to annotate whatever the "relationship" could, should, and would mean in the running service, all according to the specific domain you are modeling.
To see this confusion in action, see my discussion on
this issue opened in Puccini. I've been having this same conversation with people for years. :)