> On 24 Dec 2014, at 23:37, W Chan <m4d.co...@gmail.com> wrote:
> > 2) Retuning to first example:
> > ...
> >  action: std.sql conn_str={$.env.conn_str} query={$.query}
> > ...
> > $.env - is it a name of environment or it will be a registered syntax to 
> > getting access to values from env ?
> I was actually thinking the environment will use the reserved word "env" in 
> the WF context.  The value for the "env" key will be the dict supplied either 
> DB lookup by name, by dict, or by JSON from CLI.
Ok, probably here’s the place where I didn’t understand you before. I thought 
“env” here is just a arbitrary key that users themselves may want to have to 
just group some variables under a single umbrella. What you’re saying is that 
whatever is under “$.env” is just the exact same environment that we passed 
when we started the workflow? If yes then it definitely makes sense to me (it 
just allows to explicitly access environment, not through the implicit variable 
lookup). Please confirm.

One thing that I strongly suggest is that we clearly define all reserved keys 
like “env”, “__actions” etc. I think it’d be better if they all started with 
the same prefix, for example, double underscore.

> The nested dict for "__actions" (and all other keys with double underscore) 
> is special system purpose, in this case declaring defaults for action inputs. 
>  Similar to "__execution" where it's for containing runtime data for the WF 
> execution.

Yes, that’s clear

Renat Akhmerov
@ Mirantis Inc.

OpenStack-dev mailing list

Reply via email to