Open Stack

Hi Winson,

> On 02 Dec 2014, at 09:10, W Chan <m4d.coder at gmail.com> wrote:
> 
> 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?

Not sure what you mean by “adhoc” here. What I meant is that we should have 2 options:
Have an individual REST endpoint to be able to subscribe for certain types of events any time. For example, “Notifications about all workflow events for workflow name ‘my_workflow’” or “Notifications about switching to state ‘ERROR’ for workflow ‘my_workflow’”. Using this endpoint we can also unsubscribe from these events.
When we start a workflow (“mistral execution-create” in CLI and start_workflow() method in engine) we can configure the same subscription and pass it along with “start workflow” request. For such purposes, engine method “start_workflow” has keyword parameter “**params” that can take any kind of additional parameters needed for workflow start (for example, when we start a reverse workflow we pass “task_name”). This way we can start a workflow and configure our subscription with a single request. In the first approach we would have to make two requests.

> I propose a separate worker/executor to process the events so to not disrupt the workflow executions.  What if there are a lot of subscribers?  What if one or more subscribers are offline?  Do we retry and how many times?  These activities will likely disrupt the throughput of the workflows and I rather handle these activities separately.


Yeah, I now tend to agree with you here. Although it still bothers me because of that performance overhead that we’ll have most of the time. But generally, yes, you’re right. Do you think we should use same executors to process these notifications or introduce a new type of entity for that?

Thanks

Renat Akhmerov
@ Mirantis Inc.

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