Hi,
We spent a large portion of last year to clarify TOSCA fundamental concepts, such as profile, template, and representation graph.
- The representation graph keeps the model and the state of the service on which any actions (incl. LCM) are performed.
- It is formed from nodes (vertices) and relationships (edges).
- The templates + inputs are just used to create and initialize the representation graph.
- Requirements and capabilities are used to direct how the relationships in the representation graph are formed.
- This always happens at deployment time (after all nodes in the representation graph have been created, they will be connected)
- A target node could be identified (among all the nodes in the representation graph of this service or other services)
- by the symbolic name specified in the template
- in this case the target node will be constrained and thus planned at template design time
- can be chosen only from the template nodes (of which we know the symbolic names)
- by referring to a certain capability type, a certain node type, or by matching a certain node filter
- in this case the target node will only be known at deployment time
- this is a very important âlate bindingâ use-case where the model adapts to the template inputs and the environment
- can be chosen from both the nodes created from this template (local scope) or nodes created by other templates (external scope)
- this scope is not clearly specified in TOSCA yet, although a global scope was always expected as advertised by the TOSCA compositionality features
So, for me there is no such thing as a âdangling requirementâ, I think of it as a âworking termâ used in our discussions to represent sometimes:
- requirements that are not specifying a fixed, âsymbolic nameâ target
- requirements that cannot be satisfied by âlocalâ nodes
I also donât think there is a âdesign-timeâ or ârun-timeâ requirement, all of the relationships are established at deployment time.
Different use-cases might need that requirements are satisfied:
- locally (in the same template)
- for relationships that must be internal to the service
- note that this does not mean that a node-filter may not be used
- externally (outside of the template)
- for relationships that must be external to the service
- for service compositionality
- for service de/composition via substitution
- either local or external, just that they are satisfied
I also donât think there is such thing as a âbrokenâ representation graph. It is either connected or not connected to nodes of other services, and both are relevant as shown above.
I donât think we can replace requirements with node_filters by using the âselectâ mechanism:
- will not work if I want to use node_filters for requirements on âlocalâ nodes
- will not work if I want the target to be a capability type and not a node type
- will not work in substitutions
BR/C