Re: [tosca] Proposal for requirement "occurrences"

[Calin Curescu <calin.curescu@ericsson.com>]

Hi Tal,

 

I support both:

• symbolic names & node_filters
• local and external scope

I think all combinations of these are useful and not broken. What you want to achieve is possible with a subset of the above. I donât want to restrict the other use-cases.

 

BR/C

 

From: Tal Liron <tliron@redhat.com>
Date: Saturday, 5 February 2022 at 01:21
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: Chris Lauwers <lauwers@ubicity.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] Proposal for requirement "occurrences"

 

On Fri, Feb 4, 2022 at 4:30 PM Calin Curescu <calin.curescu@ericsson.com> wrote:

Tal, you want to restrict todayâs flexibility of requirements specification to express only static graphs fully fleshed out at design time, and I fully disagree with this.

 

I never mentioned the word "static". I'm not sure where you got it. And are you saying you want to support "dangling" requirements? I don't know what you want exactly.

 

Yes, there is only the representation graph. But during design you can still see it: put in inputs, see the resulting representation graph, and ensure that it is valid. That's all I mean by "template graph" (I keep changing my wording to try to explain better) -- it's the representation graph that you can see without having to deploy your template to the cloud. I don't mean it as a separate "thing", just as something you see at different times in your process (Day 0 vs. Day 1). The suggestion that you will never see this graph until Day 1 when it's actually running on a real cloud with real machines is what I'm fighting against. That makes Day 0 work impossible to meaningfully validate.

 

With your analogy of a motherboard having a CPU socket, here are the nodes:

 

a-cpu ->(plugs-into)-> my-motherboard

 

As you said, the motherboard is the real thing and it's assumed that the CPU will come later. It is represented here by "a-cpu" which allows me to express the design in which a CPU is plugged into the motherboard. I'll mark "a-cpu" in some way to say "user must provide this, not included in box" ("select" directive). This is the template. This is exactly the design.

 

A broken design would be this:

 

my-motherboard

 

Here I have not specified that a CPU is going to plug into the motherboard. It's broken -- meaning it's incomplete.

 

Notice, even "dangling" requirements can't help here, because they are one-way, always outgoing. And I really hope no one suggests that we add "dangling" incoming relationships, too. In this example a CPU should "require" the motherboard, but because there is no such node template there is no place for me to put that requirement. The design is not expressed and cannot be expressed without referring to a CPU.

 

That's really all there is to it.