OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

From: Tal Liron <tliron@redhat.com>
Sent: Tuesday, February 15, 2022 10:57 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Orchestration directives for requirements

 


Terminology, again.
Sorry, but this is not an issue of terminology. There is a fundamental difference between fulfilling requirements using node representations vs. fulfilling requirements using node templates.



 


Sure, it would be fulfilled by a node representation. But if we are dealing with the scope of our design then the source of those node representations is our node templates, nowhere else. This is fully reliable and fully deterministic.
We can thus validate the design before creating node representations.
Again, this is incorrect. The TOSCA spec clearly states that requirements can be fulfilled using nodes created using templates other than the topology template that includes the node template with the dangling requirement .
Please see Section 2.9. In fact, Section 2.9.1 has an explicit example of this where a host requirement must be fulfilled using an externally-created Compute node. It includes the following text in Section 2.9.1
In the example above, the
mysql component contains a
host requirement for a node of type
Compute which it inherits from its parent DBMS node type definition; however, there is no declaration or reference to any node template of type
Compute . Instead, the
mysql node template augments the abstract host
requirement with a node_filter which contains additional selection criteria (in the form of property constraints that the provider must use when selecting
or allocating a host Compute node. 



Let s please stop trying to remove functionality from the language that has been in there since v1.0. It has been very clear from the beginning that the purpose of requirements and capabilities is to allow composition
across service templates. Again, the spec states this explicitly in Section 2.9:
 
TOSCA supports two methods for template authors to express requirements for an abstract node within a TOSCA service template. 

 

1.       
Using a target node_filter : where a node template can describe a requirement (relationship) for another node without including it in the topology. Instead, the
node provides a node_filter to describe the target node type along with its capabilities and property constrains
 

2.       
Using an abstract node template : that describes the abstract node s type along with its property constraints and any requirements and capabilities it also exports. 
This first method you have already seen in examples from previous chapters where the Compute node is abstract and selectable by the TOSCA Orchestrator using the supplied Container and
OperatingSystem capabilities property constraints.
These approaches allow architects and developers to create TOSCA service templates that are composable and can be reused by allowing flexible matching of one template s requirements to another s
capabilities. Examples of both these approaches are shown below.
 


I am allowing for a reduction in that strict determinism, but I am asking that it be done explicitly, via a keyname. Again, please let's not sacrifice TOCSA's Day 0 strict validation power for Day 1 flexibility. It's possible to have both
by letting the user make an explicit choice.
 
You continue to say this, and I have asked repeatedly without any answer: what exactly do you think cannot be validated in a design if you allow dangling requirements as per the 1.3 specification?
 
Thanks,
 
Chris


 



On Tue, Feb 15, 2022 at 12:47 PM Chris Lauwers < lauwers@ubicity.com > wrote:




I think you re making an incorrect assumption that requirements are fulfilled using node templates (rather than node representations). You might be able to do this in special cases
where you don t have node filters and there is no variability in the template, but that is a special case only (and not very useful in practive). In general, if you don t explicitly assign a target in a requirement assignment, then the only time you can reliable
assign that node is at deployment time using node representations.
 
We need to get agreement on this aspect of the operational model first before we can discuss any more grammar proposals.
 

You've decided to read a lot into 2.9. It's a discussion of the idea of abstract types in TOSCA and what could be done with them. But the language is suggestive and vague and its implications are not followed through. For example: At deployment time, the provider can then do a late binding and dynamically allocate or assign the required hosting infrastructure and place software components on top. Sure, it can . But it might not. What then? How do we choose between "dynamically allocate" or "assign"? And what happens when it's no longer in use? Does TOSCA discuss garbage collection? And what if the user doesn't want the orchestrator to do any of this? The examples in 2.9.1 and 2.9.2 raise more questions than they answer. 2.9.2 at least insists on adding an explicit directive. I am following that spirit in proposing we add such a directive for 2.9.1. Let s please stop trying to remove functionality from the language that has been in there since v1.0. It has been very clear from the beginning that the purpose of requirements and capabilities is to allow composition across service templates. One of our goals for TOSCA 2.0 is to clarify vagueness. I made a concrete proposal in this email to clarify this vagueness. Using directives designers can specify exactly what they want to happen. This is very much in line with the spec. You continue to say this, and I have asked repeatedly without any answer: what exactly do you think cannot be validated in a design if you allow dangling requirements as per the 1.3 specification? I have repeatedly answered. In this email: tools like Cloudnet and Puccini have to ignore requirements that are "dangling". These tools do not deploy and do not and cannot assume an inventory or platform for "selection", "allocation" or whatever. So, yes, strictly speaking ignoring a requirement makes it "valid", but it's passing the buck to deployment time and limits what is possible to validate in Day 0. The 2.9.2 example is so, so much better for architects. It's the difference between these two designs: 2.9.1: "This is a motherboard. It has sockets for various things, like CPUs, RAM sticks, and drives." (single node with lines pointing out) 2.9.2: "This is a PC . It comprises a motherboard, a CPU, RAM sticks, and drives." (multiple nodes with lines between them) The former is a spec for a motherboard (no topology). The latter is a design of a PC (with a topology). Relatedly, it's very telling that the examples in 2.9 are explicitly about "hosting infrastructure" and "software components on top" in the context of Simple Profile's semantics, where the idea was that a virtual machine would be spun up on demand (and garbage collected? when?). Infrastructure does indeed hold a special place in design. I can imagine that some application designers would not want to think about infrastructure at all. They just want to specify the "software components on top" and let the orchestrator take care of the rest. They don't want to see these "server" node templates in the spec. But, I think they are doing it wrong and would urge them to reconsider. Working in the cloud and being cloud native means accepting that "hosting infrastructure" is itself a software component. A good, complete cloud design would make it clear what the relationships are between ALL the components. I raised the point (multiple times) that using 2.9.1 you can't specify that, say, three different software components should all run on a single server. You are leaving it up to the orchestrator to decide what is most optimal. But this is exactly the kind of decision that designers should be making. Only 2.9.2 lets you do so. But, whatever, I'm willing to concede 2.9.1, though I will always call it an anti-pattern and strongly recommend people not use it. You won this one, Chris. I think it reduces the quality of TOSCA but I want to move on. What I insist now is that we turn the suggestive language in 2.9 into clear grammar. I made a concrete proposal to introduce directives.