Open Stack

On 03/20/2014 11:11 AM, Chuck Thier wrote:
> 
>     I agree this is quite an issue but I also think that pretending that
>     we'll be able to let OpenStack grow with a minimum set of databases,
>     brokers and web servers is a bit unrealistic. The set of supported
>     technologies won't be able to fulfill the needs of all the
>     yet-to-be-discovered *amazing* projects.
> 
> 
> Or continue to ostracize current *amazing* projects. ;) 
> 
> 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.
> 
> 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.

I don't think we'd kick out an existing project over this point.  We've
already said that we don't expect existing projects to migrate an
existing API.  It's a movement to standardize for new APIs.  If swift
were building a new API, I do think it would be good to into this in
more detail.  For the existing one, I think it's fine.

Swift has more "different than everything else" issues than just library
choices.  It's a real problem IMO, but I'd rather separate that
discussion from this thread.

-- 
Russell Bryant