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
