<div>Hi everyone,<br></div><div><br></div><div>We started discussing this at the last quantum team meeting, but figured it would benefit from a broader audience. </div><div><br></div><div>There is a lot of interest from networking vendors and some open source project to integrate with OpenStack via Quantum. This is great, as this was one of the key goals of Quantum. The point of this thread is to discuss how we make sure we enable this while avoiding some potential negative side-effects. </div>
<div><br></div><div>The primary concerns seem to be: </div><div><br></div><div>1) concern that the core dev team will be overwhelmed having to review and potentially fix large amounts of vendor-specific code, taking aware their cycles from other community tasks. The concern is both that this may not be a good use of core dev time, and that the core devs may not be sufficiently familiar with the vendor backend to meaningfully review the code, and may be unable to test the code if they don't have access to the required hardware/software. </div>
<div><br></div><div>2) concern that vendors may contribute code, but not follow up to fix bugs, answer questions on the ML, update code when needed, etc. Basically, bit-rot. </div><div><br></div><div>These are not new concerns, and to date the Quantum team has had the following policy posted on the wiki (decided on during a team meeting during the Folsom cycle): </div>
<div><br></div><div>"<span style="color:rgb(83,83,83);font-family:sans-serif;font-size:14px;line-height:18px">Quantum plugins may be open source or proprietary. Some of the open source plugins are maintained in the main Quantum repository (</span><a class="" href="http://www.github.com/openstack/quantum" style="color:rgb(85,26,139);border-width:0px 0px 1px;border-bottom-style:dashed;border-bottom-color:rgb(221,221,221);text-decoration:none;font-family:sans-serif;font-size:14px;line-height:18px">http://www.github.com/openstack/quantum</a><span style="color:rgb(83,83,83);font-family:sans-serif;font-size:14px;line-height:18px">), while others are maintained in their own separate repository. As a project, we encourage plugins to be kept in the main repository for several reasons (a more cohesive developer community, better code sharing across plugins, and more uniform testing of plugins). However, we must also make sure that any plugins in the main repository remain well maintained. As a result, any plugin that is in the main repo must have at least one active member of the quantum core developer team willing to maintain it. This may be achieved by having an existing core dev agree to maintain a plugin, or by having one of the developers of the plugin become a member of the core developer team." </span></div>
<div><font color="#535353" face="sans-serif"><span style="font-size:14px;line-height:18px"><br></span></font></div><div><font face="sans-serif" color="#000000"><span style="font-size:14px;line-height:18px">Essentially, the policy is to strongly encourage people to add their plugins to the main repo, but to make sure that they also provide value to the community in return. If they do not go down this path, we still allow them to "advertise" their plugin on the Quantum wiki page, though it is hosted in an external repo, and the core team does not try to answer questions about it on the mailing list. </span></font></div>
<div><font face="sans-serif" color="#000000"><span style="font-size:14px;line-height:18px"><br></span></font></div><div><font face="sans-serif" color="#000000"><span style="font-size:14px;line-height:18px">In terms of current status, the OVS, Cisco, Linux Bridge, NVP, and NEC plugins all have core devs backing them up. </span></font><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px">The Metaplugin is maintained by someone who is not a core dev, but is very active in the community in many areas. The Ryu plugin is actively maintained, though the maintainers contributions are mostly focused on Ryu changes, and often has trouble getting core reviews. </span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px">So to date, I think we've been reasonable successfully with the current policy. I'm writing this email more because I want to get ahead of potential issues that will pop-up in grizzly, giving the exploding interest in Quantum core plugins as well as plugins/drivers for the LBaaS side of things. For example, there are several plugins already proposed (e.g., Brocade plugin, Ruijie General Operation System, Juniper, bigswitch/floodlight, hyper-v, etc) as well as many LB vendors (riverbed, radware, F5, vmware, etc.) looking to integrate. </span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px">I think the existing policy will result in us turning away some such contributions, which is sub-optimal. However, changing the policy to allow all plugins might swamp core developers, prevent them from focusing on improving the platform as a while (and ultimately making it much less attractive to be a core developer, which is VERY bad). </span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px">If we're not happy with the current state of things, one option is to</span><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px"> keep the existing policy, but also establish a 'quantum-ecosystem' repo, that let's people contribute their code to openstack quantum, though without having to go through the standard review process (instead, we'd probably have a simple model where someone is the maintainer for a particular plugin/driver and can solicit reviews from everyone, but is still able to commit regardless). This let's vendors say that they have contributed the code to quantum, without burdening the core team. This repo could have automated tests that pull in the primary quantum code as a dependency and run the same unit tests. We'd have to decide whether failures in these unit tests are just warnings, or if they would actually block commits. Distros would decide whether to include certain plugins/drivers based on demand. </span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px">A variation on this model could be keep all such code in the main Quantum repo, but enforcing different review criteria based on whether it is scoped to a single plugin or affects the whole community. This is not all that different from what happens today in practice, in that usually the core maintainer makes sure there was a thorough review from someone familiar with the plugin, then gets a second core review that focuses more on general python coding guidelines. </span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px">I'm sure there are other ideas on this as well, so feel free to offer your own. Thanks for reading :)</span></div>
<div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px">Dan</span></div><div>
<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:14px;line-height:18px"><br>
</span></div><div><br></div><div><div><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</div></div>