Hi Calin and Chris,
Thanks for your answers. They confirm the validity of the code below. Any of the two methods, pull or push, is good.
Best regards,
Arturo
From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Chris Lauwers
Sent: Wednesday, February 5, 2020 6:05 AM
To: Calin Curescu <calin.curescu@ericsson.com>; Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Question on get_attribute
In my implementation I only ever evaluate the get_attribute function when the attribute value is required somewhere (e.g. because it needs to get passed as an input, because it is necessary to evaluate a condition, or
just because the UI is trying to display current service state). Using Calinâs terminology, this type of âlazy evaluationâ would be referred as the âpull wayâ.
Chris
From:
tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Calin Curescu
Sent: Monday, February 3, 2020 5:03 AM
To: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>;
tosca@lists.oasis-open.org
Subject: Re: [tosca] Question on get_attribute
Hi,
I think that one should look at the get_attribute as an attribute propagation function, not just like a simple function. I think you can implement the get_attribute in your orchestrator in the
following ways (both are correct):
- Push way:
- When attribute A changes, then you change immediately the value of B and C, then the value of D that is based on C.
- Pull way:
- When attribute A changes, you donât do anything else.
- When you use D then you check the value of all attributes that D depends on, and so on in a depth-traversal manner. In this case here you check the value of C then the value
of A, see what that the value of A is, then you get back update the value of C, then the value of D. Note that in this case, the value of B is updated later, when it is used directly.
BR,
/C
From:
<tosca@lists.oasis-open.org> on behalf of Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>
Date: Monday, 3 February 2020 at 10:14
To: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: [tosca] Question on get_attribute
Hi Chris, Calin and all,
I would like to check what is your view on a proposal we are discussing in ETSI NFV.
We have the following excerpt from a node template:
node_templates:
SunshineDB:
type: MyCompany.SunshineDB.1_0.1_0
attributes:
call_proc_scale_level: { get_attribute: [ SELF, scale_status, call_proc, scale_level ] }
database_scale_level: { get_attribute: [ SELF, scale_status, database, scale_level ] }
where scale_status is an attribute of the same template of complex type (map), being call_proc the map key and scale_level a property of type integer.
The highlighted attribute assignments are perfectly legal from TOSCA grammar point of view.
My question is, given that scale_status is an attribute that will change value during the lifecycle of the node, would the function be re-evaluated every time scale_status changes value? i.e. would the call_proc_scale_level
and database_scale_level be updated too?
Or, if not, would they be re-evaluated at least when the call_proc_scale_level and database_scale_level are used, namely in a condition evaluation within a policy?
All the examples of get_attribute in the TOSCA spec are a bit different, they are related to 3 cases:
- output assignment
- input assignment
- property assignment (in the examples, assigning the value of an attribute from another node)
In all these cases it is very clear when the function is called.
Thanks in advance.
Best regards,
Arturo