Re: [tosca] Proposal for requirement "occurrences"

[Tal Liron <tliron@redhat.com>]

I'd rather not keep repeating myself on this.

Let's please postpone the discussion about "dangling" and focus on 2.9.2. If 2.9.2 semantically equivalent to "dangling", and we have clarity on it, then we can discuss "dangling" in that context of mutual understanding.

On Mon, Feb 7, 2022 at 11:16 AM Chris Lauwers <lauwers@ubicity.com> wrote:

Perhaps Iâm dense, but I continue to not understand why âdanglingâ requirements result in âinability to validateâ. I would argue that using dangling requirements result in increased ability to validate, since resource requirements and other dependencies are encoded directly in the design, rather than having these dependencies âhiddenâ in the implementation artifacts. Lack of the necessary resources would be exposed before you ever try to interact with the (cloud) infrastructure.

Â

Would you mind explaining what it is exactly that cannot be validated when dangling requirements are present in a topology template graph?

Â

Thanks,

Â

Chris

Â

From: Tal Liron <tliron@redhat.com>
Sent: Friday, February 4, 2022 9:20 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Proposal for requirement "occurrences"

Â

On Fri, Feb 4, 2022 at 9:27 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Day 0 validation is about checking correctness of the template (or profile), just like a compiler checks whether a program is valid. Nothing more, nothing less. Day 0 validation cannot check if the âprogramâ will never incur any runtime errors.

Â

Chris, you've sat through so many of my presentations about TOSCA, and in all of them I talk about TOSCA's ability to validate topologies before deployment. Apparently you never believed this was true.

Â

Just today I gave such a presentation to people who were quite skeptical about the business value of TOSCA. But the one thing they immediately understood was how much money could be saved by validating designs in Day 0 (using system architects) without having to set up costly lab environments (using on-the-call op engineers). Almost all the questions they asked me were about that. I evangelized TOSCA well, but at the back of my head I was imagining what the idea of "dangling" would do to their (and my) understanding of this value...

Â

Essential to checking the "correctness of the template" is its topology. That's quite different from checking the "correctness of a profile". If all your requirements are "dangling" then there is no topology, just a bullet-list BOM. And I absolutely agree with you that we can't check for "runtime errors" during this validation (and am glad you used the word "runtime" in this way, because that's exactly what I mean by it) which is why we need to avoid as much as possible any kind of runtime dependencies, especially those that would change our topologies.

Â

Again and again I've asked us to start with example 2.9.2, because that's where we seem to agree. It satisfies me because it allows for a crystal clear design topology (no postponements, no runtime, no delays, no laziness), and you've implied that it at least partially satisfies you because it's semantically equivalent to "dangling". I refer you to the most straightforward example I provided Calin regarding his motherboard+CPU design.

Â

Let's please please please try to reach clarity and consensus on 2.9.2. These philosophical and terminological arguments are leading us absolutely nowhere and are damaging our ability to work collaboratively on TOSCA 2.0.

Â

Â