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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
