[openstack-dev] [Mistral][Zaqar] Triggering Mistral workflows from Zaqar messages

Lingxian Kong anlin.kong at gmail.com
Mon May 23 02:38:08 UTC 2016


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 <zbitter at redhat.com> 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.
>
>>> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list