Re: [openstack-dev] Cells design issue
On 06/21/2013 12:16 PM, Armando Migliaccio wrote: In my view a cell should only know about the queue it's connected to, and let the 'global' message queue to do its job of dispatching the messages to the right recipient: that would solve the problem altogether. Were federated http://www.rabbitmq.com/federation.html queues and topic routing http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/ not considered fit for the purpose? I guess the drawback with this is that it is tight to Rabbit. FWIW, qpid does this, too. It wouldn't be a rabbit specific approach. I also agree that this seems like a more natural approach and is worth exploring if someone wants to dig into it some more. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cells design issue
On Fri, 2013-06-21 at 09:16 -0700, Armando Migliaccio wrote: In my view a cell should only know about the queue it's connected to, and let the 'global' message queue to do its job of dispatching the messages to the right recipient: that would solve the problem altogether. There is no global message queue in the context of cells. Were federated queues and topic routing not considered fit for the purpose? I guess the drawback with this is that it is tight to Rabbit. Again, there's no single message queue in the context of cells. I'm assuming that was to avoid a bottleneck, but Chris Behrens would be able to say better exactly why this design choice was made. All I'm doing in this discussion is trying to address one element of the current design; I'm not trying to redesign cell communication. -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cells design issue
On Jun 21, 2013, at 9:16 AM, Armando Migliaccio amigliac...@vmware.com wrote: In my view a cell should only know about the queue it's connected to, and let the 'global' message queue to do its job of dispatching the messages to the right recipient: that would solve the problem altogether. Were federated queues and topic routing not considered fit for the purpose? I guess the drawback with this is that it is tight to Rabbit. If you're referring to the rabbit federation plugin, no, it was not considered. I'm not even sure that via rabbit queues is the right way to talk cell to cell. But I really do not want to get into a full blown cells communication design discussion here. We can do that in another thread, if we need to do so. :) It is what it is today and this thread is just about how to express the configuration for it. Regarding Mark's config suggestion: On Mon, Jun 17, 2013 at 2:14 AM, Mark McLoughlin mar...@redhat.com wrote: I don't know whether I like it yet or not, but here's how it might look: [cells] parents = parent1 children = child1, child2 [cell:parent1] transport_url = qpid://host1/nova [cell:child1] transport_url = qpid://host2/child1_nova [cell:child2] transport_url = qpid://host2/child2_nova […] Yeah, that's what I was picturing if going that route. I guess the code for it is not bad at all. But with oslo.config, can I reload (re-parse) the config file later, or does the service need to be restarted? - Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cells design issue
On Fri, 2013-06-21 at 09:30 -0700, Chris Behrens wrote: On Mon, Jun 17, 2013 at 2:14 AM, Mark McLoughlin mar...@redhat.com wrote: I don't know whether I like it yet or not, but here's how it might look: [cells] parents = parent1 children = child1, child2 [cell:parent1] transport_url = qpid://host1/nova [cell:child1] transport_url = qpid://host2/child1_nova [cell:child2] transport_url = qpid://host2/child2_nova […] Yeah, that's what I was picturing if going that route. I guess the code for it is not bad at all. But with oslo.config, can I reload (re-parse) the config file later, or does the service need to be restarted? Support for reloading should get merged soon: https://review.openstack.org/32231 Cheers, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
