- My perspective is very different. In my opinion, node types (and other TOSCA types, for that matter) are the fundamental constructs from which services are created. Node types define re-usable components that can be combined with other components to construct
service topologies. It is node typesânot node templatesâthat define (component) semantics.
I understand that you think that way (it also connects to why you're sure substitution should happen at the node type level), but I disagree.
Types are schemas. This should obviously be true for data types, capability types, relationship types, policy types, group types, and artifact types. So I treat node types similarly. It breaks this basic TOSCA separation to think that node types are somehow "components". The topology_template area is where we have the components.
And I don't think this is a problem in any way. A profile designer models a domain. A topology designer takes those models and assigns them to an actual topology. That's where the types are realized. The node type defines the rules for assignment, including various default values, but not the actual assignment. It's potentiality, and is still "reusable" in that you just need to give a node template a "type" and it immediately has the potential functionality that the profile designer gave it. What it doesn't have is the actual topology, which is entirely up to the topology designer to construct, within those rules.
There's definitely room to enrich the kinds of rules baked into a node type. For an example, see my previous proposal about handling capacity. As I pointed out, I don't think counting is an especially useful rule, but it is the aspect we are discussing now. And even within counting, it's not always always the case that we would want to limit the count by range. Maybe, for example, we want to restrict it to an even number of relationships due to some kind of redundancy policy. Or it might otherwise be entirely conditional, based on various behavioral characteristics we are trying to achieve. At the end of the day TOSCA can't do absolutely everything and there will always be aspects of usage that will have to be documented so that topology designers can create topologies that are not only valid but also optimal.
Speaking of policies ... that's a possible place for us to put in these topology-wide rules. A richer policy language could allow us to constrain counts by various ways (even, odd, multiples of 16), but also introduce other kinds of relationship constraints, e.g. enforcing a multiplicity of node targets rather than allowing them to be just one node target. And even broader topological rules, for example traveling across relationship lines to, say, avoid having more than one loadbalancer along the path, or ensuring that somewhere along the path there is at least one firewall (a security policy).
Â
-
In this context, the âoccurrencesâ keyword in a requirement definition is extremely clear: it specifies the minimum number of nodes with the required capability that must be found to fulfill the requirement, and the maximum allowed number of nodes with the
required capability to fulfill the requirement.
I would not call this "extremely clear". :) Why are you assuming it should be the number of nodes and not capability "sockets" (which all might be, for example, on a single node)?
It's also very unclear just exactly how many times the requirement would end up being fulfilled, especially if you imagine a kind of "global" scope. An UNBOUNDED upper limit could imply that the orchestrator would keep trying to fulfil the requirement until it runs out of nodes. It would mean ALL THE NODES in your "global" scope All of them.
Also entirely unclear how requirement assignments fit in this in terms of refining these numbers (including with the syntactical ability to assign the same named requirement more than once). If the profile designer is to have complete control over this component, then what would it mean for a topology designer to change the numbers, even if they are a subset of the range? If the rule is a count of [ 2, 10 ] and topology designer refines it to [ 2, 4 ], wouldn't they be breaking some kind of functionality intended by the profile designer?
But you said you don't want to discuss assignments yet so I won't. :)