Hi, Zane, I think you must be interested in this: https://review.openstack.org/#/c/308664/
Regards! ----------------------------------- Lingxian Kong On Fri, May 20, 2016 at 9:49 AM, Zane Bitter <zbit...@redhat.com> wrote: > On 19/05/16 04:20, Thomas Herve wrote: >> >> On Wed, May 18, 2016 at 8:49 PM, Zane Bitter <zbit...@redhat.com> 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. > >>> 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. > >> 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. > > cheers, > Zane. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev