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 wr
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 consume
> On 02 Dec 2014, at 23:53, W Chan 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.
> Alternately, instead of
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
Hi Winson,
> On 02 Dec 2014, at 09:10, W Chan 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 “adhoc” here. What I
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 take
Renat,
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?
I propose a separate worker/executor to process the events so to not
disrupt the workflow executions. W
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
s
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 supp
11 matches
Mail list logo