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": passwd} and env2 = {"conn_str": ip2, "user": user2, "password": passwd2}. Will it be possible to do something like this: tasks: connect_first_db: action: std.sql conn_str={$.env1.conn_str} query={$.query} publish: records: $ connect_second_db: action: std.sql conn_str={$.env2.conn_str} query={$.query} publish: records: $ Thanks, Anastasia Kuznetsova On Wed, Dec 24, 2014 at 2:19 PM, Renat Akhmerov <rakhme...@mirantis.com> wrote: > > 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 wf_env will be, json file? > > > Yes. IMO it should be possible to specify either a string (name of a > previously stored environment) or a json file (so called ad-hoc > environment). > > 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 ? > > > So far we agreed that ‘key' should not be a registered key. Environment > (optionally specified) is just another storage of variables going after > workflow context in a lookup chain. So that if somewhere in a wf we have an > expression $.something then this “something” will be first looked in > workflow context and if it doesn’t exist there then looked in the specified > environment. > But if we want to explicitly group a set of variables we can use any > (except for reserved as "__actions" ) key, for example, “env”. > > 3) Can user has a few environments? > > > Yes. That’s one of the goals of introducing a concept of environment. So > that same workflows could be running in different environments (e.g with > different email settings, any kinds of passports etc.). > > > Renat Akhmerov > @ Mirantis Inc. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev