<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div>
I agree this is quite an issue but I also think that pretending that<br>
we'll be able to let OpenStack grow with a minimum set of databases,<br>
brokers and web servers is a bit unrealistic. The set of supported<br>
technologies won't be able to fulfill the needs of all the<br>
yet-to-be-discovered *amazing* projects.<br></blockquote><div><br></div><div>Or continue to ostracize current *amazing* projects. ;) </div><div><br></div><div>There has long been a rift in the Openstack community around the implementation details of swift.   I know someone mentioned earlier, but I want to focus on the fact that Swift (like marconi) is a very different service.  The API *is* the product.  With something like Nova, the API can be down, but users can still use their VM's.  For swift, if the API is down, the whole product is down.  We have a very different set of constraints that we have to work with, and thus why we often have to take very different approaches.  There absolutely can't be a one fit solution for all.</div>
<div><br></div><div>If we are going to be so strict about what an Openstack project uses, are we then by the same token going to kick swift out of Openstack because it will *never* use Pecan?  And I say that not because I think Pecan is a bad tool, just not the right tool for swift.</div>
<div><br></div><div>--</div><div>Chuck</div></div></div></div>