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 > > > > > >
