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

Thanks Tal, this is helpful. A couple more comments:
 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron
Sent: Tuesday, February 15, 2022 12:14 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Orchestration directives for requirements

 



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:
My impression is that the spec here is trying to be vague about implementations, which it should be. However, the semantics of what needs
to happen should be very clear. How things are done might be implementation-specific.


 



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.
This may be an issue that is specific to 1.3 and is no longer a concern in 2.0. The 1.x spec mandates that compatible orchestrators must
know how to create Simple Profile nodes. This is why it is possible to dynamically allocate a Compute node. In v2.0, I believe the dynamical allocation can no longer be an option, which then also avoids any garbage collection issues.


 






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.
Your approach is almost identical to the scope keyword Calin proposed several weeks ago.



 







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.
Yes, if a requirement is dangling, you cannot validate at design time that it is guaranteed to exist. But that is not a design validation
issue. That is a runtime resource availability issue, which you can never handle in a design. No matter how many resources you specify in a design, if they re not available (or cannot be created) at runtime because of resource availability issues, you ll end
up with a runtime failure. Again, this has nothing to do with design validation.


 


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 completely agree that everything that needs to be created should be specified explicitly. The only disagreement we have is that you
think everything should be in the same template.
 
There is nothing wrong with 2.9.2, expect that it is an optimization that handles the specific case where you need requirements from
different sources to be fulfilled by the same target node. But as we have discussed before, it has other problems and it doesn t justify removing the core requirements functionality.
 


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.



 
You can also do this using carefully-crafted node filters.


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.
 
We also have proposals for scope and for optional requirements. Let s discuss next week.
 
Thanks,
 
Chris

On Tue, Feb 15, 2022 at 2:57 PM Chris Lauwers < lauwers@ubicity.com > wrote: Your approach is almost identical to the scope keyword Calin proposed several weeks ago. It is similar. Calin deserves credit. :) Slightly different focus in that I'm concerned with what it means for when things can be validated: at the moment of deployment or prior. What I am proposing here is that any directive would mean "postpone", even if one of the directives is "internal". Yes, if a requirement is dangling, you cannot validate at design time that it is guaranteed to exist. But that is not a design validation issue. That is a runtime resource availability issue, which you can never handle in a design. No matter how many resources you specify in a design, if they re not available (or cannot be created) at runtime because of resource availability issues, you ll end up with a runtime failure. Again, this has nothing to do with design validation. Of course. A valid design does not guarantee it can be deployed. But a valid design is still a very valuable thing. The more you can do in Day 0, the better. 2.9.2 doesn't have this compromise between "design time" and "runtime". You specify a node template explicitly and give it a "select" directive. Your design will still be complete and valid. There's indeed no way to guarantee that there won't be a runtime error. I completely agree that everything that needs to be created should be specified explicitly. The only disagreement we have is that you think everything should be in the same template. I proposed an "external" directive, despite not liking it. So, yes, we can for 2.9.1. The only thing I ask is that it does not happen automagically. I want to make sure that if a requirement is not using directives then it means that its target can be deterministically determined on Day 0 (prior to deployment). (And, yes, the actual target on Day 1 will be a node representation not a node template. This is just about knowing deterministically in advance what will happen.) There is nothing wrong with 2.9.2, expect that it is an optimization that handles the specific case where you need requirements from different sources to be fulfilled by the same target node. But as we have discussed before, it has other problems and it doesn t justify removing the core requirements functionality. Again I suggest we start with 2.9.2 because it has the least amount of problems. But my proposal here, which I think is fairly straightforward, addresses both 2.9.1 and 2.9.2 and attempts to explain "occurrences" in relation to them.