[openstack-dev] [Mistral][Zaqar] Triggering Mistral workflows from Zaqar messages
flavio at redhat.com
Mon May 23 06:40:45 UTC 2016
On 19/05/16 17:49 -0400, Zane Bitter wrote:
>On 19/05/16 04:20, Thomas Herve wrote:
>>On Wed, May 18, 2016 at 8:49 PM, Zane Bitter <zbitter at redhat.com> wrote:
>>>I've been lobbying the Mistral developers for $SUBJECT since, basically,
>>>forever. I like to think after a couple of years I succeeded in
>>>changing their view on it from "crazy" to merely "unrealistic". In the
>>>last few months I've had a couple of realisations though:
>>>1) The 'pull' model I've been suggesting is the wrong one, architecturally
>>>speaking. It's asking Mistral to do too much to poll Zaqar queues.
>>>2) A 'push' model is the correct architecture and it already exists in the
>>>form of Zaqar's Notifications, which suddenly makes this goal look very
>>>I've posted a Zaqar spec for this here:
>>Commented. I certainly need some more time to think about it.
>Thanks, I updated the spec based on your comments.
Will take a look
>>>Not being super familiar with either project myself, I think this needs
>>>close scrutiny from Mistral developers as well as Zaqar developers to make
>>>sure I haven't got any of the details wrong. I'd also welcome any volunteers
>>>interested in implementing this :)
>>>One more long-term thing that I did *not* mention in the spec: there are
>>>both Zaqar notifications and Mistral actions for sending email and hitting
>>>webhooks. These are two of the hardest things for a cloud operator to
>>>secure. It would be highly advantageous if there were only _one_ place in
>>>OpenStack where these were implemented. Either project would potentially
>>>work - Zaqar notifications could call a simple, operator defined workflow
>>>behind the scenes for email/webhook notifications; alternatively the Mistral
>>>email/webhook actions could drop a message on a Zaqar queue connected to a
>>>notification - although the former sounds easier to me. (And of course
>>>clouds with only one of the services available could fall back to the
>>>current plugins.) Something to think about for the future...
>>And you're forgetting about Aodh alarm notifications, which are
>>webhooks as well.
>Yeah, those just need to go away :) Aodh can already post the
>notifications to Zaqar instead, and hopefully we'll be able to migrate
>everything to that method over time.
>>Unfortunately, I think none of them do a
>>particularly great job in terms of robustness and security.
>Agree. The best you can do is still middling, and we're not there yet.
Yup, I agree with the sentiment :(
>>suggested moving away from doing webhook in Zaqar to Flavio in the
>>past, and I think he responded that he thought it was part of the core
>>functionality. It's hard to delegate such operations and create a
>>dependency on another project. Maybe we can start by creating some
>I guess that's a start, but if I were running a large public cloud I'd
>probably want to isolate this on its own network surrounded by some
>pretty custom firewalls. A library doesn't really help make that
Unfortunately, I don't think a library would cut it. It'd certainly make the
code sharable but I don't know how much there is to share in this specific case.
I should look into how Aodh and other services do this.
I think one of the main problems Zaqar has now is that it doesn't have a way to
offload the webhook work to other zaqar nodes but I think we can change this
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev