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