Ok, got it.
So my general suggestion here is: let's keep it as simple as possible for now,
create something that works and then let’s see how to improve it. And yes,
consumers may be and mostly will be 3rd parties.
Thanks
Renat Akhmerov
@ Mirantis Inc.
On 09 Dec 2014, at 08:25, W Chan
Renat,
On sending events to an exchange, I mean an exchange on the transport
(i.e. rabbitMQ exchange
https://www.rabbitmq.com/tutorials/amqp-concepts.html). On implementation
we can probably explore the notification feature in oslo.messaging. But on
second thought, this would limit the
Renat,
I agree with the two methods you proposed.
On processing the events, I was thinking a separate entity. But you gave
me an idea, how about a system action for publishing the events that the
current executors can run?
Alternately, instead of making HTTP calls, what do you think if mistral
Renat,
Alternately, what do you think if mistral just post the events to given
exchange(s) on the same transport backend and let the subscribers decide
how to consume the events (i.e post to webhook, etc.) from these
exchanges? This will simplify implementation somewhat. The engine can
just
Hi Winson,
On 02 Dec 2014, at 09:10, W Chan m4d.co...@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
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).
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
Regarding blueprint to register event listeners to notify client
applications on state changes (
https://blueprints.launchpad.net/mistral/+spec/mistral-event-listeners-http),
I want to propose the following.
1. Refer this feature as event subscription instead of callback
2. Event subscription
Hi, Winson,
This is great!
But I have a question:
9. Operation in python-mistralclient to re-publish events for a given
workflow execution (in case where client applications was downed and need
the data to recover).
How does Mistral know about all the events which it has already sent to
