Open Stack

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.[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.