[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Orchestration directives for requirements
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 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.
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.
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.
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.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]