I think part of the problem with the whole Swift situation is that it does something most other OpenStack projects don't do. Its both a control plane and a data plane.
For example, Cinder provides a unified api and provides plugins to allow vendors to plug in their particular special sauce in. Through flavors, multiple plugins can be supported at once and everyone can go about doing what they do best. It isolates the vendor specific stuff from the api users expect. Swift is in a strange place where the api is implemented in a way to favor one particular vendor backend implementation. The vendor is in the tent which is good, but other vendors have legitimate reasons to implement their own variants and they can't plugin nicely to the existing thing, which is bad. So, vendors have been forced to clean room reimplement the api. This means sites can only choose one and only one Swift api endpoint, and OpenStacks can't be tested properly. There is a lot of variation in clouds here. Its a common problem, and its only going to get worse if we don't start addressing it. I think one solution would be to formalize the api as part of a plugin api, and add a control/multi-flavors service on top that the keystone service catalog returns. Initial traffic goes through it to identify which flavor to go to, and then things are redirected directly to the endpoint for the particular flavor. The current Swift implementation then has a nice place to plugin, so does radosgw, and any other vendors too. I'd love to be able to plugin Swift into our sites, but because we can only have one, the various tradoffs have lead us to deploy RadosGW most of the time. Some legitimate, non conflicting use cases of each category: * Swift's great for its advanced features, open community, etc. * RadosGW is great if you have an investment in Ceph and don't want to split your storage. It also reduces admin costs if you are Ceph already. * Other vendors provide support for stuff like tape library storage, reducing costs for backend storage. We should not be forcing operators to choose just one of these. Would this kind of rearrangement help resolve some of the issues? Language choice and in tree vs out of tree are separate discussions to testing things and being inclusive at that point. Thanks, Kevin ________________________________________ From: Monty Taylor [mord...@inaugust.com] Sent: Wednesday, May 04, 2016 12:47 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tc] supporting Go On 05/04/2016 01:31 PM, Fox, Kevin M wrote: > Explicitly, no. I agree. Implicitly... ? Why bother to even propose joining > when you know the rules clearly state that its not acceptable? I don't claim > to know what has gone on internally in such teams. I'm just saying just > because there hasn't been visible signs here of exclusion doesn't mean > exclusion hasn't happened. At no point in time has the C++ nature of ceph EVER been even an implicit blocker for any actions that were desired by either OpenStack or Ceph. There are other issues, such as it being an alternate/competing implementation to an existing OpenStack service that was not done by the existing OpenStack team. If the ceph team were to decide that they wanted to be an OpenStack project instead of an independent project, which to my knowledge has never been expressed by them as a desire, that would be the important thing to discuss - and it's a thing that should not be taken lightly. As it is, the desire has not be expressed, nor has it be deflected, nor has it been blocked. If any of those things _had_ happened, C++ would not have been nor would it be a relevant or interesting part of the discussion. > Thanks, > Kevin > ________________________________________ > From: Pete Zaitcev [zait...@redhat.com] > Sent: Wednesday, May 04, 2016 10:40 AM > To: Fox, Kevin M > Cc: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [tc] supporting Go > > On Tue, 3 May 2016 22:37:30 +0000 > "Fox, Kevin M" <kevin....@pnnl.gov> wrote: > >> RadosGW has been excluded from joining the OpenStack community in part >> due to its use of c++. > > Sounds like sheer lunacy. Nothing like that ever happened, AFAIK. > > -- Pete > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
