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).
Renat Akhmerov
@ Mirantis Inc.
On 17 Sep 2014, at 17:07, Angus Salkeld <asalk...@mirantis.com> wrote:
> On Thu, Sep 18, 2014 at 4:25 AM, Renat Akhmerov <rakhme...@mirantis.com>
> wrote:
> Ok, here is what I think...
>
> 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).
>
> 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):
>
> POST /executions
> workflow_name=flow
> callbacks=[{
> events: [[on-task-complete, on-execution-complete]
> action: std.http url=‘http://foo.bar.com' method=POST headers=‘{}' ##
> },
> {# another callback}
> ]
>
> and/or
>
> POST /executions
> workflow_name=flow
> callbacks=[{
> events: [[on-task-complete, on-execution-complete]
> action: std.http
> parameters: {
> url: http://foo.bar.com,
> method: POST
> headers: {
> # Whatever headers we need.
> }
> }
> },
> {# another callback}
> ]
>
> In other word we can trivially generalise this so that:
> we can use not only webhooks but any action accessible in Mistral (e.g. it
> may be other transport)
> it is consistent with our DSL
>
> We might even want to allow “workflow” as well as “action” but not sure if we
> need to get that far for now.
>
> Thoughts?
>
> [0]
> https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-amqp
> [1]
> https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-http
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> On 17 Sep 2014, at 10:36, Dmitri Zimine <dzim...@stackstorm.com> wrote:
>
>> Use case:
>> 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.
>>
>> Solution is a webhook
>>
>
>
> I think another good solution is a zaqar queue/inbox. To me this is even
> better as you can send updates on
> each task that runs not just the whole workbook. This provides much better
> feedback to the user.
> (we are looking at something like this in Heat).
>
> in this case you just need the name of the queue/inbox.
>
> -Angus
>
>
>> Option 1: pass callback URL as part of starting workflow execution:
>> POST /executions
>> workflow_name=flow
>> callback= {
>> events: [[on-task-complete, on-execution-complete]
>> url: http://bla.com
>> method:POST
>> headers: {}
>> … other stuff to form proper HTTP call, like API tokens, etc ...
>> }
>> …..
>>
>>
>> Option 2: webhook endpoint
>> Mistral exposes /webhook controller
>> Client creates a webhook and receives events for all executions for selected
>> workflows.
>> {
>> "name": "web",
>> "active": true,
>> "events": [ ]
>> “workflows”: [wf1, wf2]
>> "url": "http://example.com/webhook";,
>> }
>>
>> Opinions:
>>
>> DZ: my opinion:
>> Option 1 for it is simple and convenient for a client.
>> It seems like an optimal solution for “tracking executions and tasks” use
>> case.
>>
>> 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).
>>
>> I vaguely recall someone from Heat compared these options and regretted one
>> of them for security reasons, but can’t remember details.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
