Open Stack

Ok.

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 subscription.
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.

Thanks

Renat Akhmerov
@ Mirantis Inc.



> On 12 Nov 2014, at 22:21, W Chan <m4d.coder at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/ad421440/attachment.html>