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