<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>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. :)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Thierry Carrez<br>
<b>Sent:</b> Monday, May 09, 2016 1:53:06 AM<br>
<b>To:</b> openstack-dev@lists.openstack.org<br>
<b>Subject:</b> Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Fox, Kevin M wrote:<br>
> 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.<br>
> [...]<br>
<br>
Yes, it is certainly part of the Go rationale (I wouldn't say <br>
"problem"). Swift implementing a data plane has more performance <br>
constraints and therefore replacing critical parts of it (of not all of <br>
it) in Go makes more sense there than anywhere else in OpenStack.<br>
<br>
To your other point, it is also true that Swift does not act as an <br>
integration engine for available object storage technologies, and <br>
therefore is a bit unique in the OpenStack landscape.<br>
<br>
Splitting Swift into two components (an OpenStack API/integration <br>
front-end and a pluggable separate object storage backend) was suggested <br>
in the past. The main objection to such a split by Swift developers was <br>
that there is no good split line in the Swift codebase -- the API <br>
frontend would end up being extremely thin. Maybe the lines moved over <br>
the last 3 years, but I doubt it.<br>
<br>
There is of course little internal incentive in the Swift team to work <br>
on such decoupling (since they are 99% focused on the Swift engine). To <br>
make it really happen would probably require a separate team driving it <br>
and/or a more... radical change on the governance side. The fact that <br>
there is no such team forming (or more support for radical change) <br>
suggests that the situation is not critically broken...<br>
<br>
-- <br>
Thierry Carrez (ttx)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>