<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 15, 2014 at 7:55 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Tue, Jul 15, 2014 at 8:56 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>

> John Griffith wrote:<br>
>> [...]<br>
>> Anyway, I'd like to get some feedback from the TC on all of this.<br>
>>  Whether it be an official agenda item for an upcoming meeting, or at<br>
>> the very least feedback to this email.  In my opinion this is very much<br>
>> a TC item and is exactly the sort of thing that the TC should be<br>
>> interested in.  I can certainly make decisions on my own based on<br>
>> feedback from the rest of the Cinder community and my own personal view,<br>
>> however I believe this has a broader impact.<br>
><br>
> The TC is responsible for the "scope" of OpenStack and making sure we<br>
> spend our common resources where they are the most needed, so I think<br>
> it's relevant for us to at least give our opinion there.<br>
><br>
> There are IMHO two different issues here. The first is a technical<br>
> issue: what type of functionality you want your drivers to cover. In<br>
> Cinder, drivers should be a relatively thin indirection layer where you<br>
> implement the glue between the Cinder driver API on one side and what<br>
> the pure storage backend expects on the other. They are not really<br>
> supposed to be big or reimplement advanced scheduling features.<br>
> Accepting such monster drivers in mainline code changes the relative<br>
> weight of code areas in cinder and therefore makes it a costly<br>
> maintenance proposition for the project, with little on the benefits<br>
> side compared to growing that driver out of tree.<br>
><br>
> The second issue is more of a social issue: we want as much as possible<br>
> of the smart in Cinder being implemented in open source in OpenStack. If<br>
> vendors decide to implement the smart parts in closed source software<br>
> shipped in storage hardware gateways, they may win but OpenStack surely<br>
> loses.<br>
><br>
> I think it's a perfect example of where out-of-tree makes the most<br>
> sense: when the added value to the project is limited (or negative),<br>
> while the benefit for one vendor is enormous.<br>
<br>
</div></div>We also need to keep in mind the DefCore discussions, and the TC<br>
position that the code the community delivers in the integrated<br>
release should be used as the "designated sections". Vendors want to<br>
use the trademark. We want them to contribute to core. Working<br>
together on their drivers in the tree is part of the bargain, and it<br>
would be a huge mistake to push them out.<br>
<br>
If this particular driver reproduces too much existing cinder<br>
functionality in a way that can't be reused, that's both a technical<br>
issue and a project management issue. Maybe the new initiative to<br>
bring product managers into the community will address it in the<br>
future by helping them to understand how to work on features with the<br>
community. In the mean time I don't have a problem with the Cinder<br>
team responding to this contribution that it duplicates functionality<br>
in their core, and is therefore not an appropriate implementation for<br>
a driver. As long we suggest changes rather than rejecting it<br>
entirely, that sort of review is part of the process. Would a spec<br>
review have caught this earlier?<br>
<br>
We should also consider writing down guidelines for what sort of<br>
functionality should and should not be included in the various driver<br>
layers, to help vendors understand our expectations.<br>
<span class=""><font color="#888888"><br>
Doug<br>
</font></span><div class=""><div class="h5"><br>
> The other classic example of this is the Nova VMWare support... and it's<br>
> questionable as well on both counts. That said the dynamics are slightly<br>
> different there, VMWare being the legacy standard for old-style<br>
> datacenter virtualization, supporting it is a decent way to co-opt that<br>
> ecosystem and encourage migrating off it.<br>
><br>
> --<br>
> Thierry Carrez (ttx)<br>
><br>
> _______________________________________________<br>
> OpenStack-TC mailing list<br>
> <a href="mailto:OpenStack-TC@lists.openstack.org">OpenStack-TC@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
<br>
_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org">OpenStack-TC@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">> solutions. So vmware for example is built so we don't have a</span><br style="font-family:arial,sans-serif;font-size:12.727272033691406px">
<span style="font-family:arial,sans-serif;font-size:12.727272033691406px">> nova-compute per hypervisor node, but one per cluster, and then rely</span><br style="font-family:arial,sans-serif;font-size:12.727272033691406px">
<span style="font-family:arial,sans-serif;font-size:12.727272033691406px">> on vsphere to do all the cluster leg work. This isn't as bad as it</span><br style="font-family:arial,sans-serif;font-size:12.727272033691406px">
<span style="font-family:arial,sans-serif;font-size:12.727272033691406px">> sounds like it is in cinder, but is still a watering down in the value</span><br style="font-family:arial,sans-serif;font-size:12.727272033691406px">
<span style="font-family:arial,sans-serif;font-size:12.727272033691406px">> of nova.</span><br></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div class="gmail_extra">
<span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Good analogy, however also keep in mind in this model you're not just plugging in Vendor-X's product, you're also saying you can plug in Vendor-X, Y and Z's product (in the case of EMC that list includes at least 4 drivers that exist in Cinder, this would be a way to have support in tree/openstack without having to go through the OpenStack processes).  I see this as good and bad personally, until it comes to bug reports and maintenance.  I also don't see how you possibly test these models in the General OpenStack framework.  Burden is on the Vendor here (and it's a significant burden).</span></div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="color:rgb(80,0,80)">> Accepting such monster drivers in mainline code changes the relative</span><br style="color:rgb(80,0,80)">
<span style="color:rgb(80,0,80)">> weight of code areas in cinder and therefore makes it a costly</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">> maintenance proposition for the project, with little on the benefits</span><br style="color:rgb(80,0,80)">
<span style="color:rgb(80,0,80)">> side compared to growing that driver out of tree.</span></div><div class="gmail_extra"><br style="color:rgb(80,0,80)"><font color="#500050">This is one of my biggest concerns on the topic, particularly as these Vendors historically provide nothing in terms of Core Cinder contribution, and in fact some of them are banned by their company from working on anything other than their Companies driver submission.</font></div>
<div class="gmail_extra"><font color="#500050"><br></font></div><div class="gmail_extra"><font color="#500050"><br></font></div><div class="gmail_extra"><font color="#500050">I like Mark's optimism, however I'm a bit more cynical after working in Cinder for a while.  Keep in mind as I mentioned earlier some companies like EMC still won't allow their employees to contribute anywhere except their drivers (based on conversations I've had with EMC management), although they are working on changing that.</font></div>
<div class="gmail_extra"><font color="#500050"><br></font></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">> One other observation about your request, John. It reminds me of John Dickinson's original move of all swift-related code to outside > of the code base. He may be able to comment better about whether it was about onboarding contributors or about maintenance</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">> burden. I think it was the maintenance that concerned him.</span><font color="#500050"><br></font></div><div class="gmail_extra">
<span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Yeah, I think there were a number of motivations there; the idea of not having drivers in tree period is not something I really want, especially not the way SWIFT does it.  What I've been thinking about over the years was a way to test and contribute driver integration as it's own separate effort but still under the umbrella and sanctioning of OpenStack; but I haven't figured out a good way to do that so we should ignore that piece.  It's not something I'm prepared to tackle or that I think is that big of a deal right now.</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">My current take on this is:</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">If you have what I've dubbed an UBER driver that abstracts multiple backend devices it's a case by case basis.</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">1. Are you developing this to enable a Software Defined Storage solution (ie turning a cluster of servers or jbods into a full featured storage product).  If yes, then 'ok', even though it's a loop-hole when you also support a multitude of other vendors.</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">2. Does your UBER driver provide support for a backend device that is NOT already available and maintained in Cinder?  If NO then your offering probably doesn't make much sense, and I'd very much welcome your suggestions/improvements to the Cinder version of those drivers that already exists.</span></div>
<div class="gmail_extra"><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div class="gmail_extra"><font face="arial, sans-serif">That's about the best, least subjective I can really come up with at this point.  It's either that or it's back to my original stance of "if you abstract out multiple backends, and implement a secondary scheduler you're out".  Those have been the two approaches I've gone back and forth on.</font></div>
<div class="gmail_extra"><font face="arial, sans-serif"><br></font></div><div class="gmail_extra"><font face="arial, sans-serif">One of the arguments that gets thrown out a lot is "if it doesn't work and it doesn't get support, just remove it", but the reality is that's a very difficult thing to do.  Even if there are just a handful of customers that go down this path, removing support for their configuration is not something that I would like to do, no matter how painful supporting them might be.</font></div>
</div>