On Thu, Sep 18, 2014 at 7:55 AM, Flavio Percoco <fla...@redhat.com> wrote: > On 09/18/2014 04:24 PM, Clint Byrum wrote: >> Great job highlighting what our friends over at Amazon are doing. >> >> It's clear from these snippets, and a few other pieces of documentation >> for SQS I've read, that the Amazon team approached SQS from a _massive_ >> scaling perspective. I think what may be forcing a lot of this frustration >> with Zaqar is that it was designed with a much smaller scale in mind. >> >> I think as long as that is the case, the design will remain in question. >> I'd be comfortable saying that the use cases I've been thinking about >> are entirely fine with the limitations SQS has. > > I think these are pretty strong comments with not enough arguments to > defend them. >
Please see my prior email. I agree with Clint's assertions here. > Saying that Zaqar was designed with a smaller scale in mid without > actually saying why you think so is not fair besides not being true. So > please, do share why you think Zaqar was not designed for big scales and > provide comments that will help the project to grow and improve. > > - Is it because the storage technologies that have been chosen? > - Is it because of the API? > - Is it because of the programing language/framework ? It is not because of the storage technology or because of the programming language. > So far, we've just discussed the API semantics and not zaqar's > scalability, which makes your comments even more surprising. - guaranteed message order - not distributing work across a configurable number of back ends These are scale-limiting design choices which are reflected in the API's characteristics. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
