Open Stack

On 27/04/15 10:44 -0700, Joe Gordon wrote:
>
>
>On Fri, Apr 24, 2015 at 5:19 PM, Zane Bitter <zbitter at redhat.com> wrote:
>
>    On 24/04/15 20:00, Joe Gordon wrote:
>   
>       
>
>        On Fri, Apr 24, 2015 at 4:35 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov
>        <mailto:Kevin.Fox at pnnl.gov>> wrote:
>
>            Notification might be a good way to integrate with nova. Individual
>            tenants might want to do things as vm's come up/down, etc. Right
>            now, you need a privileged pipe into rabbit. Forwarding them to
>            Zaqar, per tenant queue's could solve the problem.
>
>
>        Right now you can poll the nova API. Or tenants can use any number of
>        monitoring tools.  How does zaqar better then the alternatives?
>   
>
>    So, a couple of points about that:
>
>     1) Polling sucks.
>     2) If a bunch of things are going to get polled, at least collect them
>    together so there is *one* thing to optimise for massive polling load.
>    (Zaqar is this thing - you have to poll it too atm.)
>     3) Long-polling and WebSockets suck a lot less than polling. If you
>    already collected all the polling in one place, it's really easy to make
>    the switch as soon as you implement them in that one place.
>     4) If you don't have a common place to poll, then you can't use the events
>    as triggers for other services in OpenStack (without writing custom polling
>    code for every endpoint in every API - which is pretty much what Heat does
>    now, but that work doesn't extend automatically to Mistral, Congress, &c.
>    in the way that Zaqar notifications could.)
>
>    Also, APIs tend to only return the current status. You could miss events if
>    you just poll the API, whereas if the events are dispatched to a durable
>    queue and you just poll the queue for events, that problem goes away. 
>
>   
>
>        FWIW, I think there are some really neat use cases for amazon SQS, that
>        presumably Zaqar would fit as well. Cases such as
>        https://aws.amazon.com/articles/1464
>
>
>    Bingo, this is where it starts to get really interesting.
>
>
>Instead of asking the community to come up with reasons to integrate with
>Zaqar, I think it would be more effective if the Zaqar team came up with one or
>two use cases they want to support that require integration with other projects
>and go from there. Turn this abstract call for adoption into a more narrow but
>concrete proposal for X and Y to integrate with Zaqar to support a specific use
>case. 

The Zaqar team has done this several times in these last 2 years. The
latest info that was collected is written here [0] and here [1]. These
use cases were discussed in the Kilo summit [2] and we reached an
agreement with people from other teams. Unfortunately, some priorities
changed and the integration didn't happen in Kilo.

This thread is more a call for action rather than a beg for adoption.
The team knows what the use cases are but we cannot force them into
projects if they are not willing to adopt it. With the very limited
resources we have, we need to be *very* careful on where our time is
spent. Therefore, we need to know what projects are indeed willing to
consume Zaqar so that we can help them with such efforts.

[0] https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases
[1] https://etherpad.openstack.org/p/zaqar-overcloud-use-cases
[2] https://etherpad.openstack.org/p/kilo-zaqar-summit-integration-with-services

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150428/d6d482a3/attachment.pgp>