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
On 02 Dec 2014, at 23:53, W Chan m4d.co...@gmail.com wrote: 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? Yes, sounds great! I really like the idea.
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
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