On 27 Dec 2014, at 01:39, W Chan m4d.co...@gmail.com wrote:
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
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.
Yes.
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.
I absolutely agree here. We should use specific keywords with __ prefix
like we used
Winson, Renat,
I have a few questions, because some of aspects aren't clear to me.
1) How does the end user will pass env variables to workflow?Will you add
one more optional parameter to execution-create command?
mistral execution-create wf wf_input wf_params wf_env
If yes than what is wf_env
On 24 Dec 2014, at 14:06, Anastasia Kuznetsova akuznets...@mirantis.com
wrote:
1) How does the end user will pass env variables to workflow?Will you add one
more optional parameter to execution-create command?
mistral execution-create wf wf_input wf_params wf_env
If yes than what is
Renat,
thanks for response!
One more question:
So that same workflows could be running in different environments
Asking about using a few environments I meant within one workflow. For
example I need to work with two DB and I have two environments: env1 =
{conn_str: ip, user: user, password:
Trying to clarify a few things...
* 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
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
Thanks Winson,
Since we discussed all this already I just want to confirm that I fully support
this model, it will significantly help us make much more concise, readable and
maintainable workflows. I spent a lot of time thinking about it and don’t see
any problems with it. Nice job!
However,
