Not exactly what I meant. Take a plugin that talks to the cloud you mentioned. One option is to have the plugin "fill in" the value in the orchestrator. Another implementation is to fetch the value on demand. The plugin writer provides the function, not the target system. The following happens now (for the compute IP address example):
1. install workflow run on template, compute node plugin fetches IP address and stores it in an attribute. 2. a dependent node grabs the IP attribute and does whatever. This is implemented as an ARIA storage fetch. What I'm suggesting: 1. install workflow run on template, compute node doesn't fetch IP. 2. a dependent node grabs the IP attribute, which results in a call to the cloud to fetch the value. IOW, there are never two copies of the state, at least in persistent storage. I'm not suggesting this for the ip_address example, but other use cases would benefit. Note that the default "getter" for attributes could simply fetch the value from ARIA storage. DeWayne On Wed, Nov 15, 2017 at 1:23 PM, Tal Liron <t...@cloudify.co> wrote: > 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 <dewa...@cloudify.co> > 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 > > >
