Yes. Permit a function to be an attribute value. This would apply to both context and intrinsic evaluation.
On Thu, Nov 16, 2017 at 12:18 PM, Tal Liron <[email protected]> wrote: > I'm not entirely sure what you are saying here. My guess is that you mean > something like this: > > When setting an attribute value via ctx, you want ARIA to be able to set > function values. For example, this is just a regular value: > > ctx set my_attribute "plain string value" > > You are saying that we should also support this: > > ctx set my_attribute "{ get_property: [ SELF, property_name ] }" > > In which case you expect ARIA to actually evaluate the function when you > retrieve the value of my_attribute. Am I understanding you correctly? > > > On Thu, Nov 16, 2017 at 1:55 PM, DeWayne Filppi <[email protected]> > wrote: > > > What I'm talking about has nothing to do with TOSCA. It only has to do > > with the orchestrator. Accessing an attribute has nothing to do with > > operations. > > > > On Thu, Nov 16, 2017 at 11:46 AM, Tal Liron <[email protected]> wrote: > > > > > DeWayne, what you asking for might be achievable via the > > > "get_operation_output" function. This function is not very well defined > > in > > > TOSCA, but it seems that the expectation is that every operation can > > return > > > an untyped key-value dict. This has nothing to do with attributes per > se, > > > but behind the scenes works quite similarly. > > > > > > But, if you really you want something more dynamic ("call to the cloud" > > as > > > you say), that doesn't exist in TOSCA right now. It could be possible > to > > > add such a feature to ARIA, but it would not be portable. > > > > > > Steve, seems that you understand it correctly. > > > > > > > > > > > > > > > > > > On Thu, Nov 16, 2017 at 1:25 PM, Steve Baillargeon < > > > [email protected]> wrote: > > > > > > > Hi > > > > A follow-up question. > > > > I am trying to understand the meaning of "function" here. > > > > > > > > Is the solution as simple as defining an attribute (say of type > > string), > > > > skip the attribute assignment in the template and let the plugin > > decides > > > > the "value" for the attribute which can be a calculated value or any > > > > function implemented by the plugin? Yes I agree this is not portable. > > > > Did I miss something? > > > > > > > > -Steve > > > > > > > > -----Original Message----- > > > > From: Tal Liron [mailto:[email protected]] > > > > Sent: Wednesday, November 15, 2017 4:24 PM > > > > To: [email protected] > > > > Subject: Re: attributes > > > > > > > > Well, this is a bit complex. > > > > > > > > Attributes are ostensibly filled during runtime by other systems, for > > > > example during the install workflow an ip_address would get its real > > > value. > > > > It's not really clear how another system would be able to insert a > > > > function here, but it's not impossible. In ARIA's case, functions are > > > > implemented as pickled Python classes, so it would be possible to do > > > this, > > > > however obviously it would not be portable. > > > > > > > > But, you can also give attributes default values. For default values, > > > > obviously you can use functions. > > > > > > > > On Wed, Nov 15, 2017 at 2:51 PM, DeWayne Filppi <[email protected] > > > > > > wrote: > > > > > > > > > General TOSCA question. Is there anything in the spec that > requires > > > > > attributes to be values rather than functions? IOW, is there > > anything > > > > > in there that prevents an orchestrator from representing an > attribute > > > > > read as more of a "getter", rather than a database fetch? I ask > > > > > because I've run across a case where I'd prefer an attribute > > reference > > > > > to return a calculated value. Seems more flexible if allowed, and > if > > > > > not allowed, it should be allowed. > > > > > > > > > > DeWayne > > > > > > > > > > > > > > >
