I'm not sure there is any reason to mention it in TOSCA, but that's OK. It also would allow lazy evaluation by node types. Some rarely used attributes might cause slow performance in a non-lazy plugin.
On Thu, Nov 16, 2017 at 12:36 PM, Tal Liron <[email protected]> wrote: > I do have some ideas for expanding TOSCA to support "operation types" that > would allow more flexibility exactly for these use cases. My article about > it might be coming out soon! > > On Thu, Nov 16, 2017 at 2:34 PM, DeWayne Filppi <[email protected]> > wrote: > > > True, the roots are in functional programming. In any case, I don't > think > > serializing lambdas is going to cut it. The attribute accessor could be > > calling the Openstack python libraries. IMHO, this happens by executing > > code in the context of the plugin. The persistent store could have some > > kind of "reference" (not a real reference of course) that could be > > recognized as a path to a python package and function. In any case, > I'll > > JIRA it up. > > > > DeWayne > > > > On Thu, Nov 16, 2017 at 12:28 PM, Tal Liron <[email protected]> wrote: > > > > > Well, this is *kinda* supported in ARIA right now. > > > > > > It *is* supported via the Python API: you can create an instance of any > > > function class (such as GetProperty) and it will be serialized the > > storage > > > and evaluated upon retrieval. > > > > > > But it is *not* supported via ctx in Bash. If we want to support this, > we > > > would also need to find a syntax for doing so (ctx right now would have > > no > > > idea if you mean to use a plain string or mean to instantiate a > > function). > > > > > > If you feel this is a useful feature, feel free to open a JIRA for it. > > > Please describe it in as much detail as possible and perhaps add some > > > practical use cases for the feature. > > > > > > (By the way, I don't see this as an issue of programming languages > moving > > > from structs to accessors, but an issue of functional programming. > > > Functional programming languages treat functions as "first-class > > citizens", > > > so that they can be passed around by value. The TOSCA spec has nothing > to > > > say about this, but it is something we can support quite easily because > > we > > > built ARIA in Python, which does have this functional aspect.) > > > > > > On Thu, Nov 16, 2017 at 2:21 PM, DeWayne Filppi <[email protected]> > > > wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
