It sounds like we all agree that fulfilling dangling requirements will always result in complete and valid node representation graphs (assuming suitable target nodes can be found) which in the end is all that matters.
Tal is correct that target nodes used for dangling requirements will not have a corresponding node template in the service design, but I honestly donât understand why this is a problem. Is there anything that canât be validated, or that
introduces ambiguity, or that increases the likelihood of errors? Or is this strictly an issue of esthetics and personal preference?
Thanks,
Chris
From: Tal Liron <tliron@redhat.com>
Sent: Friday, February 4, 2022 9:39 AM
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Proposal for requirement "occurrences"
Thanks Calin, that's quite clear.
I just want to clarify what I mean by "runtime: true".
It's true that requirements are functionally fulfilled and relationships are created at "deployment time". I did not intend to dispute that. But they should be able to be fully and determenistically validated at "design time" merely
by providing inputs. The goal is to give the deployment a validated, known, well-designed graph. That's the core conceit of declarative approaches to orchestration.
I offered "runtime: true" as a compromise to satisfy Chris. Chris would like to allow some requirements to be fulfillable
only at "deployment time", meaning that during "design time" (Day 0) you will not -- and
cannot -- see a full graph. At design time you will see an edge going out but no vertex. So the only way to validate designs that use such a feature is to actually deploy them in a real environment (I call it the "runtime environment" as opposed to the
"design environment"; that's the source of my "runtime" keyword). I don't like this feature at all, but OK, he insists it is important.
I'm also happy to find another name for it, but I don't think it should be "scope". The issue is not the
source of the node representations. The issue is that there is no target node template for the requirement in the design.
And there never will be. Even if the requirement is fulfilled, that fulfillment is not shown or named in the design. The node representation graph might be complete, but the TOSCA design graph is not. It's a node without a node template. Unfortunately,
Chris is right in calling this feature "dangling". I don't like the word, but it does describe what is happening.
Some other potential names for this keyword:
-
external: true
(here we are explicitly saying that the requirement's target is external to the design; I like this one) -
target: external
(this is even more explicit and maybe closest to Calin's proposed "scope"; the default value would be "internal", I guess; this might appeal most to you because you don't seem to like talking about the WHEN of the requirement, and here we are avoiding that
by referring to the nature of the target node) -
abstract: true
(this matches the old language in the TOSCA spec; I understand it to mean that the target node is abstract, i.e. not specified or named in the design; but some people might understand it as the requirement being abstract? not entirely clear to me but for some
people it might make the most sense; possibly closest in meaning to Chris's "dangling") -
fulfill: false
(we are saying: "avoid fulfilling this requirement during validation"; but could be misunderstood by reader to imply "never fulfill this") -
optimistic: true
(as in "optimistic locking" for databases, whereby you assume it's safe to move on without actually locking; here we are assuming that a requirement is going to be fulfilled later and can, for the purposes of design validation, be considered valid even if it's
not fulfilled) -
lazy: true
(this is a why to talk about WHEN without being specific; obviously some negative connotations to this word so not so great; but is used a lot in software) -
postpone: true
(again, seems like you don't like talking about the WHEN, but this one makes sense to me)
Hi,
We spent a large portion of last year to clarify TOSCA fundamental concepts, such as profile, template, and representation graph.
-
The representation graph keeps the model and the state of the service on which any actions (incl. LCM) are performed.
-
It is formed from nodes (vertices) and relationships (edges).
-
The templates + inputs are just used to create and initialize the representation graph.
-
Requirements and capabilities are used to direct how the relationships in the representation graph are formed.
-
This always happens at deployment time (after all nodes in the representation graph have been created, they will be connected)
-
A target node could be identified (among all the nodes in the representation graph of this service or other services)
-
by the symbolic name specified in the template
-
in this case the target node will be constrained and thus planned at template design time
-
can be chosen only from the template nodes (of which we know the symbolic names)
-
by referring to a certain capability type, a certain node type, or by matching a certain node filter
-
in this case the target node will only be known at deployment time
-
this is a very important âlate bindingâ use-case where the model adapts to the template inputs and the environment
-
can be chosen from both the nodes created from this template (local scope) or nodes created by other templates (external scope)
-
this scope is not clearly specified in TOSCA yet, although a global scope was always expected as advertised by the TOSCA compositionality features
So, for me there is no such thing as a âdangling requirementâ, I think of it as a âworking termâ used in our discussions to represent sometimes:
-
requirements that are not specifying a fixed, âsymbolic nameâ target
-
requirements that cannot be satisfied by âlocalâ nodes
I also donât think there is a âdesign-timeâ or ârun-timeâ requirement, all of the relationships are established at deployment time.
Different use-cases might need that requirements are satisfied:
-
locally (in the same template)
-
for relationships that must be internal to the service
-
note that this does not mean that a node-filter may not be used
-
externally (outside of the template)
-
for relationships that must be external to the service
-
for service compositionality
-
for service de/composition via substitution
-
either local or external, just that they are satisfied
I also donât think there is such thing as a âbrokenâ representation graph. It is either connected or not connected to nodes of other services, and both are relevant
as shown above.
I donât think we can replace requirements with node_filters by using the âselectâ mechanism:
-
will not work if I want to use node_filters for requirements on âlocalâ nodes
-
will not work if I want the target to be a capability type and not a node type
-
will not work in substitutions
BR/C
|