Re: [tosca] Proposal for requirement "occurrences"

[Tal Liron <tliron@redhat.com>]

We are indeed getting hung up on terminology.

I don't entirely disagree with your analogy, though like all analogies it can only go so far. A Java class is not just a struct, it also supplies methods, including virtual methods. So Java classes provide implementations. We do have interfaces/operations in TOSCA, but the actual implementations (artifacts) are not part of the language. And also TOSCA has an extra level that programming languages do not: type -> template -> representation. And TOSCA introduces the concept of "refinement" in a way that doesn't make sense when considering Java objects. For Java there are only inheritance rules.

Anyway, the devil is in the details of requirements, a feature that has no Java equivalent. I think it would be more productive to stick to the topic.

I think the core issue is that you care more about runtime ("dangling") requirements. For you, fulfilling requirements is (primarily?) the job of the orchestrator, not the processor.

I'd like to suggest a compromise.

1) Let's all go over section 2.9.2 together, carefully. To me this is the best way to achieve runtime fulfilment, as it keeps TOSCA's graph intact. You said that it is semantically equivalent to "dangling" requirements. So, if we can get everybody on board with 2.9.2 and its implications then I think it would be a good starting point.

2) Though I think 2.9.2 is the right way to do it, I'm willing to compromise with the idea of allowing requirement fulfilments to be postponed to runtime, simply because it seems like you'll never agree that 2.9.2 should be the only way to achieve it. However, I cannot agree that this feature would be automatically defined by a heuristic. I would insist that there would be a keyword that a user would have to explicitly set for requirement assignments (and I would discourage people from using it). I dislike the word "dangling" for various reasons, so I would suggest something like "runtime: true". (Calin's suggestion of a "scope" keyword doesn't make much sense to me, because the important aspect is the WHEN and not the WHERE.) In essence the keyword just tells the processor: skip this requirement. It's not your responsibility. It will be fulfilled instead by the orchestrator on Day 1 at the moment the topology is deployed, assuming the orchestrator supports this feature. I imagine many orchestrators can't do this easily if at all, because they would consume the TOSCA topology as an input and cannot go back and change it. (You'll see this in action in my upcoming TOSCA for Ansible demo.) Unless you add an initial pre-orchestration phase ... but I wouldn't consider it worth the effort when 2.9.2 does everything needed without this awkwardness.

3) There are so many implications to this feature that I am uncomfortable with, and so I'll insist that we need to be explicit about them in the spec. For example, without an actual target node template in the design then doing something like "get_property: TARGET" can't work until after deployment.

On Tue, Feb 1, 2022 at 9:57 PM Chris Lauwers <lauwers@ubicity.com> wrote:

 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.

Â

Perhaps weâre getting hung up on terminology. Letâs try an analogy. Letâs assume Iâm a âprofile designerâ who models a domain. But letâs say I use Java rather than TOSCA. I would then define Java classes to model the âentitiesâ in the domain. My Java program would use âinstancesâ of those classes to define specific functionality using âentitiesâ in my domain.

Â

Using TOSCA, I would define Node Types to define âclassesâ of entities in the domain. These âclassesâ represent what I called the reusable components. Service topologies are the âprogramsâ where âinstancesâ of the Node Types are realized. Note that I donât like to use âinstancesâ here, because we are really only creating âtemplatized instancesâ that allow for deployment-time variability as previously explained by Peter. The real âinstancesâ are created by applying deployment-specific inputs to the âtemplatizedâ instances (resulting in what we have previously defined the âinstance modelâ but are now calling ârepresentationsâ).

Â

Using this analogy, Node Types are like Classes in Java, and node templates are âtemplatized instancesâ of those classes. However, just like in Java, the component-specific behavior is defined in the Node Types (the âclassesâ), not the instances. Given that TOSCA is a graph grammar (using Peterâs comments earlier), this behavior must include definitions of how the relationships must/can be formed between entities. As I stated earlier, using this analogy, requirement definitions arenât just a grammatical construct used for validation, they are a fundamental _expression_ of other components on which this component depends in order to function correctly.

Â

So, just like Java classes arenât just schemas, TOSCA Node Types also arenât just schemas. They define the primitive components (and their associated behavior), instances of which can be used to create service topology graphs.

Â

Chris

Â

Â

Â