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