Open Stack

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.[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160523/e70a9d8f/attachment.pgp>