Open Stack

On Feb 7, 2014, at 11:12 AM, Chris Behrens <cbehrens at codestud.com> wrote:

> 
> On Feb 7, 2014, at 8:21 AM, Jesse Noller <jesse.noller at 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
> 

Definitely +1 - we’re talking solutions and technology when the requirements aren’t clear - I mean, heck - some might want to use Celery/etc, some might want to use cloud queues and other things on the server side. I’d like to help get us to a point where we could enable operators to swap in the client side and server side things that work best for their topology