OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.

 

 

cidimage001.png@01D5DA9A.34EA3280

 

                

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]