Open Stack

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)