> 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
