RE: [tosca] Towards an instance model for TOSCA

[Chris Lauwers <lauwers@ubicity.com>]

Sounds like more areas for differences of opinions. Comments in-line:

 

 

I agree with all your points in essence, but am looking at it differently. To an extent, I am saying that all requirements are really "dangling", because they are really requirements for node templates rather than for node instances.

 

This may be at the core of our different views. In my opinion, a requirement is absolutely a requirement for a node instance. Iâm not sure what it would mean to have a requirement for a template. That wouldnât allow me to express resource requirements.

 

I am arguing that the node template is a good way to express the parameters of the requirement. That "inventory" of nodes you mentioned -- well, a node template is exactly how you can tell the orchestrator what should be in that inventory.

 

 

TOSCA has explicit support for specifying that a node needs to be fulfilled from inventory rather than instantiated. This is done by using the âselectâ directive in a node template and defining an associated node filter that contains the âquery parametersâ. This is an alternative to dangling requirements, typically used when you want to be explicit about the fact that the same node must be used to fulfill requirements from multiple other nodes.

 

Or let's put it another way: imagine we didn't have "requirements" and only, as you put it, "explicit relationships". That would actually still be fine in my view, and still allow for the exact same "dangling". Let's image we had such a grammar:

 

node_templates:

  my_app:

    relationships:

    - host: my_server

 

  my_server:

    properties:

      arch: x86

      ram: 16 gb

 

I do not read this as "hey orchestrator, provision one server for me and install an app on it".

 

I think that is exactly what it means.

 

Actually, I'm not even sure what that would mean -- "my_server" is a template for nodes, but how many nodes? I don't know.

 

As of right now, the answer is âexactly oneâ. While the spec alludes to scaling and creating multiple instances from the same template, it doesnât actually talk about how this should be done. The spec introduces a Scalable capability, which would suggest that nodes that are scalable should advertise this capability. However, this is clearly a mis-use of what capabilities are for. Capabilities only exist for the purpose of terminating relationships, not as an alternative way to express orchestration behavior. If orchestration behavior must be specified, it should be done using features in the language. We currently have no language features to deal with the general issue of âmultiple instancesâ.

 

In my opinion, this is the next big topic we should tackle. In my opinion, this is the biggest hole in the spec right now. We need to:

 

• Introduce language support to specify whether it is possible to instantiate multiple node instances from a given node template
• Introduce language support to specify whether multiple node instances created from the same template are all logically identical (the âscalingâ scenario) and as a result all take the same property values, or whether multiple instances all have their own roles (e.g the âCCVPNâ scenario in ONAP) and as a result may need different property values.
• Introduce language support to mark a given node as optional (something that currently is not supported at all)
• Specify how creating multiple instances affects relationships

 

And how many instances of the app need to be installed? I don't know, maybe it's a Kubernetes pod with 50 containers in it.

 

If thatâs the case, you wouldnât model a âmy_serverâ, since you wouldnât create virtual machines if youâre using Kubernetes. In addition, this raises the question of how the instance model should represent this: do we expect one node instance that represents the entire pod (with all 50 containers) or do we expect to see 50 nodes, one for each container?

 

I don't really care in terms of designing my topology.

 

I agree, but you absolutely do care at runtime. For the instance model to have value, it should be as accurate a representation of the real deployment as possible.

 

Those numbers depend on scaling, redundancy policies, and cloud-native decisions. When designing topologies for Kubernetes you actually might relinquish control over numbers of instances entirely, and then configure certain controllers to manage those numbers for you. Even numbers of "relationships" could be controlled: imagine the relationship is a configured network connection to a database server. For redundancy perhaps two such connections would be formed, each to a different container instance in a pod. So I read this design this way: "hey orchestrator, when and if you provision or schedule servers, and also provision or schedule app instances, then those specific app instances should be installed on those specific servers". The way in which this happens might be quite complex indeed. In other words: I'm desigining a relationship, not giving a command to create a relationship.

 

That interpretation is different from what is currently in the TOSCA spec, in my opinion. Relationship (templates) exist for the sole purpose of creating relationships (which is why relationships have interfaces and operations, which touches on another comment you made in your earlier email).

 

In yet other words: A node template represents a potential for actual nodes, while a "relationship" -- even when entirely explicit, as in this case! -- represents a potential for a actual relationships between those actual nodes. This grammar, to me, represents exactly that "dangling" aspect you mention.

 

Sounds like we need to get agreement on the core abstractions:

 

• In my opinion, a template exists for the sole purpose of âcreating instances from a templateâ. This applies to both node templates as well as relationship templates. They donât express a âpotentialâ, they define âintentâ.
• Dangling requirements are not templates. Instead, they define a âqueryâ: orchestrator, please go find me something! This is also not a âpotentialâ, this is a âneedâ.

 

Am I arguing that we should remove the "requirements" grammar, then? Well, I do think it's nice for designers: it automates some design work, and also gives some power for creating node types with both flexibility and strong validation. Since TOSCA 1.0 I've found it quite useful.

 

If I understand your use of dangling requirements correctly, then all your dangling requirements must be fulfilled using node templates in the same service template that also includes the dangling requirements (since everything else is outside the scope of what a service template has access to). Iâm not sure how this is useful.

 

But it's useful only as long as we understand that it's an entirely design-time grammar. But if it helps reduce confusion -- and there's always been plenty of confusion regarding the "requirements-and-capabilities" feature -- then, yes, let's throw away that grammar and make all relationships explicit. Cloudify does that and doesn't seem less usable than TOSCA for its supported use cases.

Yes, I had planned to add a chapter to the spec that clarifies the intended use of dangling requirements, which is to find nodes in an external inventory. Sounds like we need more discussion before I can go ahead and do that 😊

 

Thanks

 

Chris