[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):
BR, /C From: <tosca@lists.oasis-open.org> on behalf of Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com> 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, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]