Here’s what I think.

Mostly I like the solution you’re proposing. Some comments/questions:
We discussed this with Dmitry about a couple of months ago and we concluded 
that we don’t necessarily need a separate endpoint, CRUD operations etc. (even 
though my initial BP had exactly this idea). One of the reasons was that we can 
just attach required information about events we’re interested in to “start 
workflow” request (technically it may be that “params” argument in 
“start_workflow” method) so that you don’t need to make 2 requests: 1) 
Subscribe to required events 2) Start workflow. However, I think we could 
combine these two things: having a separate endpoint and being able to attach 
“callback” information (the naming should be different though) in “start 
workflow” request. The first option is useful when I’m not interested in some 
particular workflow. For example, if I as a Mistral client just want to monitor 
what’s happening with my multiple workflows (not certain executions but rather 
all executions of specific workflows) and want to react on them somehow. The 
second one is just a shortcut solution to avoid one extra request to make event 
Having only decorators is not enough. Even though I like that idea indeed. For 
instance, the event of completing workflow can’t be handled by a decorator I 
guess. But I’m not 100% sure, it may actually depend on how smart that 
decorator is. Anyway, just a thought.
Do you think we need a separate worker/executor connected via MQ to make all 
the notifications? Would it be simpler to just make those HTTP calls directly 
from engine w/o distributing them? Seems like distribution overhead may be 
higher than making the call itself. Btw, we’re now thinking about the concept 
of ‘local actions’ that don’t have to be distributed across executors. The 
reason is the same: distribution overhead is much higher than just running them 
right in the engine process. So I would like to know what you think here.


Renat Akhmerov
@ Mirantis Inc.

> On 12 Nov 2014, at 22:21, W Chan <m4d.co...@gmail.com> wrote:
> 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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to