On 27/04/15 10:44 -0700, Joe Gordon wrote:
On Fri, Apr 24, 2015 at 5:19 PM, Zane Bitter <zbit...@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....@pnnl.gov <mailto:kevin....@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
pgpcUovyZvBMG.pgp
Description: PGP signature
__________________________________________________________________________ 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
