Open Stack

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 at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160509/0bfea3a7/attachment.html>