<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Well, event types are supposed to be different depending on what we want.. I just like the idea of using actions because corresponds to spirit of Mistral :) Btw, zaqar can be easily supported in a form of action (again, to be consistent with what we do in the system).<div><br><div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br class="Apple-interchange-newline">
</div>
<br><div><div>On 17 Sep 2014, at 17:07, Angus Salkeld <<a href="mailto:asalkeld@mirantis.com">asalkeld@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 18, 2014 at 4:25 AM, Renat Akhmerov<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;">Ok, here is what I think...<div><br></div><div>I totally support the first option for its easiness in terms of understanding how it all should work (no need to figure out if some additional objects must be deleted if a workflow has been removed etc. etc.). We actually have two BPS [0] and [1] where the idea was similar to your option #2. But I admit that they’ve been around for a while and I think are obsolete (even though having eventually the same goal of notifying the outside world about executions/tasks events).</div><div><br></div><div>The only thing I would like to suggest is how we define a callback (keeping in mind it should be a valid JSON in reality):</div><div><br></div><div><div>POST /executions<br> <span class="Apple-converted-space"> </span>workflow_name=flow<br> <span class="Apple-converted-space"> </span>callbacks=[{</div><div> <span class="Apple-converted-space"> </span>events: [[on-task-complete, on-execution-complete]</div><div><span style="white-space: pre-wrap;"> </span>action: std.http url=‘<a href="http://foo.bar.com'" target="_blank">http://foo.bar.com'</a><span class="Apple-converted-space"> </span>method=POST headers=‘{}' ##</div><div> <span class="Apple-converted-space"> </span>},</div><div> {# another callback}</div><div> ]<br><br></div><div>and/or</div><div><br></div><div>POST /executions<br> <span class="Apple-converted-space"> </span>workflow_name=flow<br> <span class="Apple-converted-space"> </span>callbacks=[{</div><div> <span class="Apple-converted-space"> </span>events: [[on-task-complete, on-execution-complete]</div><div><span style="white-space: pre-wrap;"> </span>action: std.http</div><div><span style="white-space: pre-wrap;"> </span>parameters: {</div><div><span style="white-space: pre-wrap;"> </span>url:<span class="Apple-converted-space"> </span><a href="http://foo.bar.com/" target="_blank">http://foo.bar.com</a>,</div><div><span style="white-space: pre-wrap;"> </span>method: POST</div><div><span style="white-space: pre-wrap;"> </span>headers: {</div><div><span style="white-space: pre-wrap;"> </span># Whatever headers we need.</div><div><span style="white-space: pre-wrap;"> </span>} </div><div><span style="white-space: pre-wrap;"> </span>}</div><div> <span class="Apple-converted-space"> </span>},</div><div> {# another callback} </div><div> ]</div></div><div><br></div><div>In other word we can trivially generalise this so that:</div><div><ul><li>we can use not only webhooks but any action accessible in Mistral (e.g. it may be other transport)</li><li>it is consistent with our DSL</li></ul></div><div><br></div><div>We might even want to allow “workflow” as well as “action” but not sure if we need to get that far for now.</div><div><br></div><div>Thoughts?</div><div><br></div><div>[0] <a href="https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-amqp" target="_blank">https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-amqp</a></div><div>[1] <a href="https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-http" target="_blank">https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-http</a></div><div><br><div><div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br></div><br><div><div><div class="h5"><div>On 17 Sep 2014, at 10:36, Dmitri Zimine <<a href="mailto:dzimine@stackstorm.com" target="_blank">dzimine@stackstorm.com</a>> wrote:</div><br></div></div><blockquote type="cite"><div class="h5"><div style="word-wrap: break-word;"><b>Use case: </b><br>The client software fires the workflow execution and needs to be know when the workflow is complete. There is no good pool strategy as workflow can take arbitrary time from ms to days. Callback notification is needed. <br><font color="#007316"><br></font>Solution is a webhook<br><font color="#007316"><br></font></div></div></blockquote></div></div></div></blockquote><div><br></div><div>I think another good solution is a zaqar queue/inbox. To me this is even better as you can send updates on<br></div><div>each task that runs not just the whole workbook. This provides much better feedback to the user.<br></div><div>(we are looking at something like this in Heat).<br><br></div><div>in this case you just need the name of the queue/inbox.<br></div><div><br></div><div>-Angus</div><div><br> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;"><div><blockquote type="cite"><div><div class="h5"><div style="word-wrap: break-word;"><div><font color="#007316"></font><b>Option 1: pass callback URL as part of starting workflow execution:</b><br>POST /executions<br> <span class="Apple-converted-space"> </span>workflow_name=flow<br> <span class="Apple-converted-space"> </span>callback= {</div><div> <span class="Apple-converted-space"> </span>events: [[on-task-complete, on-execution-complete]</div><div> <span class="Apple-converted-space"> </span>url: <a href="http://bla.com/" target="_blank">http://bla.com</a><br> <span class="Apple-converted-space"> </span>method:POST<br> <span class="Apple-converted-space"> </span>headers: {}<br> <span class="Apple-converted-space"> </span>… other stuff to form proper HTTP call, like API tokens, etc ...<br> <span class="Apple-converted-space"> </span>}<br> <span class="Apple-converted-space"> </span>…..<br><font color="#007316"><br><br></font><b>Option 2: webhook endpoint</b><br>Mistral exposes /webhook controller <br>Client creates a webhook and receives events for all executions for selected workflows. <br>{ <br> <span class="Apple-converted-space"> </span>"name": "web",<br> <span class="Apple-converted-space"> </span>"active": true,<br> <span class="Apple-converted-space"> </span>"events": [ ]<br> <span class="Apple-converted-space"> </span>“workflows”: [wf1, wf2] <br> <span class="Apple-converted-space"> </span>"url": "<a href="http://example.com/webhook" target="_blank">http://example.com/webhook</a>", <br>}<br><font color="#007316"><br></font><b>Opinions: </b><br><br></div><div>DZ: my opinion: <br>Option 1 for it is simple and convenient for a client. <br>It seems like an optimal solution for “tracking executions and tasks” use case.<br><font color="#007316"><br></font>Option 2 is an overkill: makes it harder for a client (post workflow, post webhook, post execution, delete workflow, delete webhook) introduces lifecycle management problems (e.g., workflow deleted -> webhook orphaned).<br><font color="#007316"><br></font><div style="word-wrap: break-word;"><div style="word-wrap: break-word;"><div>I vaguely recall someone from Heat compared these options and regretted one of them for security reasons, but can’t remember details.</div><div><br></div></div></div></div><br></div></div></div>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote></div><br></div><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></blockquote></div><br></div></div>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></blockquote></div><br></div></body></html>