Yeah, the data plane api is much more complicated then the control plane. I agree the control api would be a pretty thin api. But just because its thin doesnt mean its not increadibly useful. :)
Also, just because the community isnt screaming yet doesnt mean its not really broken. We tend to put up with a lot of brokenness for a long time. The lack of desire to split the two by swift makes sence. It forces some sites to have to use the implementation. It also makes sense though for them to allow it. Then swift might be added as an additional flavor to clouds that normally wouldnt. I think if we raised the question of team forming to the storage vendors that have alternate swift data plane implementations, some developers to do the work might start showing up. I know we had to turn down a few of them this summit since they couldnt replace our existing endpoint. It can take a little while for the message to make it from the sales teams to developer teams. Does the tc have an established channel to them to ask the question? If not, cinder has a pretty good channel I think. Maybe that could be used. Thanks, Kevin ________________________________ From: Thierry Carrez Sent: Monday, May 09, 2016 1:53:06 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go Fox, Kevin M wrote: > 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. > [...] Yes, it is certainly part of the Go rationale (I wouldn't say "problem"). Swift implementing a data plane has more performance constraints and therefore replacing critical parts of it (of not all of it) in Go makes more sense there than anywhere else in OpenStack. To your other point, it is also true that Swift does not act as an integration engine for available object storage technologies, and therefore is a bit unique in the OpenStack landscape. Splitting Swift into two components (an OpenStack API/integration front-end and a pluggable separate object storage backend) was suggested in the past. The main objection to such a split by Swift developers was that there is no good split line in the Swift codebase -- the API frontend would end up being extremely thin. Maybe the lines moved over the last 3 years, but I doubt it. There is of course little internal incentive in the Swift team to work on such decoupling (since they are 99% focused on the Swift engine). To make it really happen would probably require a separate team driving it and/or a more... radical change on the governance side. The fact that there is no such team forming (or more support for radical change) suggests that the situation is not critically broken... -- Thierry Carrez (ttx) __________________________________________________________________________ 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
