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 <[email protected]> wrote:I've been lobbying the Mistral developers for $SUBJECT since, basically, forever.[1][2][3] I like to think after a couple of years I succeeded in changing their view on it from "crazy" to merely "unrealistic".[4] 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 realistic indeed. I've posted a Zaqar spec for this here: https://review.openstack.org/#/c/318202/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 :(
I 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 library code.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 easier.
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 easily enough. Flavio -- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
