On Feb 7, 2014, at 8:21 AM, Jesse Noller <jesse.nol...@rackspace.com> wrote:
> It seems that baking concurrency models into the individual clients / > services adds some opinionated choices that may not scale, or fit the needs > of a large-scale deployment. This is one of the things looking at the client > tools I’ve noticed - don’t dictate a concurrency backend, treat it as > producer/consumer/message passing and you end up with something that can > potentially scale out a lot more. I agree, and I think we should do this with our own clients. However, on the service side, there are a lot of 3rd party modules that would need the support as well. libvirt, xenapi, pyamqp, qpid, kombu (sits on pyamqp), etc, come to mind as the top possibilities. I was also going to change direction in this reply and say that we should back up and come up with a basic set of requirements. In this thread, I think I’ve only seen arguments against various technology choices without a clear list of our requirements. Since Chuck has posted in the meantime, I’m going to start (what I view) should be some of our requirements in reply to him. - Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
