+1
Lingxian, keep up with the good work. :D
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/
Here's the etherpad link. I replied to the comments/feedbacks there.
Please feel free to continue the conversation there.
https://etherpad.openstack.org/p/mistral-resume
__
OpenStack Development Mailing List (not for usage que
Resending to see if this fixes the formatting for outlines below.
I want to continue the discussion on the workflow "resume" feature.
Resuming from our last conversation @
http://lists.openstack.org/pipermail/openstack-dev/2015-March/060265.html.
I don't think we should limit how users resume.
I want to continue the discussion on the workflow "resume" feature.
Resuming from our last conversation @
http://lists.openstack.org/pipermail/openstack-dev/2015-March/060265.html.
I don't think we should limit how users resume. There may be different
possible scenarios. User can fix the environm
Mistral Team and Friends,
Thank you for giving me the opportunity to become core member of the
Mistral team. I have an absolute blast developing and using Mistral. I'm
happy with the current progress and direction that Mistral is heading. I
look forward to many more collaborations and contributio
We assume WF is in paused/errored state when 1) user manually pause the WF,
2) pause is specified on transition (on-condition(s) such as on-error), and
3) task errored.
The resume feature will support the following use cases.
1) User resumes WF from manual pause.
2) In the case of task failure, us
As a user of Mistral pretty regularly these days, I certainly prefers <%
%>. I agree with the other comments on devops familiarity. And looking
this from another angle, it's certainly easier to type <% %> then the other
options, especially if you have to do this over and over again. LOL
Although
> 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
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
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
Renat,
We want to introduce the concept of an ActionProvider to Mistral. We are
thinking that with an ActionProvider, a third party system can extend
Mistral with it's own action catalog and set of dedicated and specialized
action executors. The ActionProvider will return it's own list of action
Renat, Dmitri,
On supplying the global context into the workflow execution...
In addition to Renat's proposal, I have a few here.
1) Pass them implicitly in start_workflow as another kwargs in the
**params. But on thinking, we should probably make global context
explicitly defined in the WF spe
Renat,
Here's the blueprint.
https://blueprints.launchpad.net/mistral/+spec/mistral-runtime-context
I'm proposing to add *args and **kwargs to the __init__ methods of all
actions. The action context can be passed as a dict in the kwargs. The
global context and the env context can be provided her
Nikolay,
Regarding whether the execution environment BP is the same as this global
context BP, I think the difference is in the scope of the variables. The
global context that I'm proposing is provided to the workflow at execution
and is only relevant to this execution. For example, some context
Renat,
Is there any reason why Mistral do not pass action context such as workflow
ID, execution ID, task ID, and etc to all of the action executions? I
think it makes a lot of sense for that information to be made available by
default. The action can then decide what to do with the information.
Renat,
On sending events to an "exchange", I mean an exchange on the transport
(i.e. rabbitMQ exchange
https://www.rabbitmq.com/tutorials/amqp-concepts.html). On implementation
we can probably explore the notification feature in oslo.messaging. But on
second thought, this would limit the consume
Renat,
I agree with the two methods you proposed.
On processing the events, I was thinking a separate entity. But you gave
me an idea, how about a system action for publishing the events that the
current executors can run?
Alternately, instead of making HTTP calls, what do you think if mistral
Renat,
Alternately, what do you think if mistral just post the events to given
exchange(s) on the same transport backend and let the subscribers decide
how to consume the events (i.e post to webhook, etc.) from these
exchanges? This will simplify implementation somewhat. The engine can
just take
Renat,
To clarify on the shortcut solution, are you saying 1) we add an adhoc
event subscription to the workflow spec OR 2) add a one time event
subscription to the workflow execution OR both?
I propose a separate worker/executor to process the events so to not
disrupt the workflow executions. W
Nikolay,
You're right. We will need to store the events in order to re-publish.
How about a separate Event model? The events are written to the DB by the
same worker that publishes the event. The retention policy for these
events is then managed by a config option.
Winson
_
Regarding blueprint to register event listeners to notify client
applications on state changes (
https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-http),
I want to propose the following.
1. Refer this feature as event subscription instead of callback
2. Event subscription supp
it.
>
>
> Inviting everyone to discussion.
>
> Thanks
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> On 28 Aug 2014, at 06:17, W Chan wrote:
>
> Renat,
>
> It will be helpful to perform a callback on completion of the async
> workflow. Can we add on-finish
Renat,
It will be helpful to perform a callback on completion of the async
workflow. Can we add on-finish to the workflow spec and when workflow
completes, runs task(s) defined in the on-finish section of the spec? This
will allow the workflow author to define how the callback is to be done.
He
On 31 May 2014, at 04:26, W Chan wrote:
>
> Is there an existing unit test for testing enabling keystone middleware in
> pecan (setting cfg.CONF.pecan.auth_enable = True)? I don't seem to find
> one. If there's one, it's not obvious. Can someone kindly point me to it
Thanks.
Winson
On Fri, Jun 6, 2014 at 9:12 AM, W Chan wrote:
> Renat,
>
> Regarding blueprint
> https://blueprints.launchpad.net/mistral/+spec/mistral-engine-executor-protocol,
> can you clarify what it means by worker parallelism and engine-executor
> parallelism?
> Cur
Renat,
Regarding blueprint
https://blueprints.launchpad.net/mistral/+spec/mistral-engine-executor-protocol,
can you clarify what it means by worker parallelism and
engine-executor parallelism?
Currently, the engine and executor are launched with the eventlet driver
in oslo.messaging. Once a mess
Is there an existing unit test for testing enabling keystone middleware in
pecan (setting cfg.CONF.pecan.auth_enable = True)? I don't seem to find
one. If there's one, it's not obvious. Can someone kindly point me to it?
On Wed, May 28, 2014 at 9:53 AM, W Chan wrote:
> Th
gt; >
> > On 17/05/14 02:48, W Chan wrote:
> >> Regarding config opts for keystone, the keystoneclient middleware
> already
> >> registers the opts at
> >>
> https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_t
thing like CONF.import(_transport_opts,
> “oslo.messaging.transport”, “transport”)? And use it by passing the group,
> not entire contfig, like:
>
> transport = messaging.get_transport(cfg.messaging.CONF)
> instead of
> transport = messaging.get_transport(cfg.CONF)
>
> DZ>
>
at 1:13 PM, W Chan wrote:
> Currently, the various configurations are registered in
> ./mistral/config.py. The configurations are registered when mistral.config
> is referenced. Given the way the code is written, PEP8 throws referenced
> but not used error if mistral.config is re
Currently, the various configurations are registered in
./mistral/config.py. The configurations are registered when mistral.config
is referenced. Given the way the code is written, PEP8 throws referenced
but not used error if mistral.config is referenced but not called in the
module. In various
overwrites the ERROR previously set in here
> http://tinyurl.com/q5lps2h
>
> Nicolay, any better explanation?
>
>
> DZ>
>
> On Mar 26, 2014, at 6:20 PM, W Chan wrote:
>
> Regarding
> https://github.com/stackforge/mistral/blob/master/mistral/engine/scalable/execu
Regarding
https://github.com/stackforge/mistral/blob/master/mistral/engine/scalable/executor/server.py#L123,
should the status be set to SUCCESS instead of RUNNING? If not, can
someone clarify why the task should remain RUNNING?
Thanks.
Winson
___
OpenS
Fri, Mar 21, 2014 at 3:20 AM, Renat Akhmerov wrote:
> Alright, thanks Winson!
>
> Team, please review.
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> On 21 Mar 2014, at 06:43, W Chan wrote:
>
> I submitted a rough draft for review @
> https://review.openstac
Can the long running task be handled by putting the target task in the
workflow in a persisted state until either an event triggers it or timeout
occurs? An event (human approval or trigger from an external system) sent
to the transport will rejuvenate the task. The timeout is configurable by
the
Congratulation to the new core reviewers!
On Wed, Mar 19, 2014 at 10:54 PM, Renat Akhmerov wrote:
> Thanks, guys!
>
> Done.
>
> On 20 Mar 2014, at 02:28, Timur Nurlygayanov
> wrote:
>
> > Also, in the future, we can join Kirill Izotov to the core team too.
>
> Absolutely, once in a while we'll
gt;
> >
> > On 14 Mar 2014, at 05:14, Dmitri Zimine wrote:
> >
> >> We have access to all configuration parameters in the context of
> api.py. May be you don't pass it but just instantiate it where you need it?
> Or I may misunderstand what you're trying
7;m looking at
https://github.com/stackforge/mistral/blob/master/mistral/cmd/api.py#L50and
https://github.com/stackforge/mistral/blob/master/mistral/api/app.py#L44.
Do you have any suggestion? Thanks.
On Thu, Mar 13, 2014 at 1:30 AM, Renat Akhmerov wrote:
>
> On 13 Mar 2014, at 10:40, W Cha
he same transport in
order to have the Queue in scope. Thus, we will need some method to have
this transport object visible to all three components and hence my proposal
to use a global variable and a factory method.
On Tue, Mar 11, 2014 at 10:34 PM, Renat Akhmerov wrote:
>
> On 12
I want to propose the following changes to implement the local executor and
removal of the local engine. As mentioned before, oslo.messaging includes
a "fake" driver that uses a simple queue. An example in the use of this
fake driver is demonstrated in test_executor. The use of the fake driver
r
ing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, February 25, 2014 at 11:30 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [opens
so what can be
> specifically except RabbitMQ?
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> On 26 Feb 2014, at 14:30, Nikolay Makhotkin
> wrote:
>
> Looks good. Thanks, Winson!
>
> Renat, What do you think?
>
>
> On Wed, Feb 26, 2014 at 10:00 AM, W Cha
inson
On Mon, Feb 24, 2014 at 8:07 PM, Renat Akhmerov wrote:
>
> On 25 Feb 2014, at 02:21, W Chan wrote:
>
> Renat,
>
> Regarding your comments on change https://review.openstack.org/#/c/75609/,
> I don't think the port to oslo.messaging is just a swap from pika to
&g
ink through other executor/engine communications.
>
> We talked about executor communicating to engine over 3 channels (DB,
> REST, RabbitMQ) which I wasn't happy about ;) and put it off for some time.
> May be it can be rationalized as part of your design.
>
> DZ.
>
&g
2014, at 8:31 PM, Renat Akhmerov
> wrote:
> >
> >>
> >> On 25 Feb 2014, at 07:12, W Chan wrote:
> >>
> >>> As I understand, the local engine runs the task immediately whereas
> the scalable engine sends it over the message queue to one or more
Will Mistral be supporting custom actions developed by users? If so,
should the Actions module be refactored to individual plugins with a
dynamic process for action type mapping/lookup?
Thanks.
Winson
___
OpenStack-dev mailing list
OpenStack-dev@lists.o
As I understand, the local engine runs the task immediately whereas the
scalable engine sends it over the message queue to one or more executors.
In what circumstances would we see a Mistral user using a local engine
(other than testing) instead of the scalable engine?
If we are keeping the local
Renat,
Regarding your comments on change https://review.openstack.org/#/c/75609/,
I don't think the port to oslo.messaging is just a swap from pika to
oslo.messaging. OpenStack services as I understand is usually implemented
as an RPC client/server over a messaging transport. Sync vs async calls
48 matches
Mail list logo
