> On 27 Dec 2014, at 01:39, W Chan 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
> > environment, not thr
> 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.
Y
>
> 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 use
> On 24 Dec 2014, at 23:37, W Chan 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 thinkin
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 environm
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, "passwor
> On 24 Dec 2014, at 14:06, Anastasia Kuznetsova
> 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 wf_env will be, json
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 wi
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, a
After some online discussions with Renat, the following is a revision of
the proposal to address the following related blueprints.
*
https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment
* https://blueprints.launchpad.net/mistral/+spec/mistral-global-context
*
https://bluepri
10 matches
Mail list logo
