We need to have a session about this at the summit that takes into account the needs of vendors, core developers, and packagers/deployers.
I'm hoping we can come to something that works better for everyone. Vish On Feb 15, 2012, at 9:50 AM, Dan Wendlandt wrote: > Hi Aaron, > > Thanks for raising this. Interestingly, I think Nova is dealing with > similar questions with respect to drivers, so I'm adding Vish to the > thread as well. My feeling is that the decision of whether > plugin/driver code is kept in the main repos and reviewed by core devs > should probably be made consistently across openstack projects (or at > least have clear guidance from the policy board). Below are some > initial thoughts I have that provide some background for the > discussion. > > To date, we have real experience with two plugins, one that can be run > entirely with OS components and one that requires proprietary hardware > and software to test. I expect moving forward we will have more of > both types. Already there is no assumption that core devs test either > type of plugins, due to the concerns you've mentioned. All unit > testing is done with a basic "FakePlugin". It is possible for plugin > developers to easily run those unit tests against their own plugins as > well, but plugin developers themselves are responsible for this. > Likewise, there is not assumption that core openstack resources will > contribute plugin specific documentation, as that is also the > responsibility of the plugin developer. > > Still, I share your concern that the amount of plugin code is growing > more quickly than the number of core devs able to review. I don't > want core devs so swamped with reviewing plugin code that they can't > make progress on the base Quantum platform. One approach would be to > just let people commit code to the quantum/plugins sub-directory > without review, but I think that is likely to lead to a mess of poorly > maintained code in an official openstack repo, which I don't like. > Another option, as you suggest, is to have all plugins in separate > repos. Splitting things out makes it a bit more complex to even get a > basic setup running from a dev perspective, but probably doesn't > impact end-users too much, as they will be installing using packages > anyway. Splitting out is unlikely to change current testing + > documentation procedures, as they are already the responsibility of > the plugin "owner". > > One major reasons people probably want to get their plugins merged is > for visibility, so that when people see the set of plugins available, > their plugin is on the list. We can probably solve this visibility > problem more easily by just providing a public registry that people > can add to in order to publicly announce the set of plugins. This > would also hopefully address another concern about splitting out the > repos, which is how distributions like Ubuntu, Red Hat, Debian, etc. > would learn about new plugins they may want to package. > > One other issue, if we decided to go with a split, would be how we > handle code that needs to be shared among a set of plugins. To some > degree, this could be handled on an adhoc basis (creating yet more > repos), but it definitely adds to complexity. > > I'd also want to think more about what this means for API extensions. > My goal is that while an API extension may be proposed by a particular > plugin first, if this extension is designed in a generic way, it would > be able to be leveraged by other plugins and (perhaps after some > additional tweaks), become part of the standard API. In your > thinking, would extensions live in the main code base, or with plugins > (or an option for both)? > > As I said, I think this question is probably broader than just > Quantum, though the pain may be the most acute with Quantum, given the > small core team and the surging interest in plugins. Would be curious > to get input from others on how they see it. > > Dan > > > On Wed, Feb 15, 2012 at 5:02 AM, Aaron Lee <aaron....@rackspace.com> wrote: >> We have several plugins in Quantum currently, and several more waiting for >> review. Several plugins ares currently waiting for review, and this problem >> is only going to get worse. We don't have enough core devs, who are very >> familiar with the underlying systems, to properly evaluate the plugins. I >> don't think this problem is going to go away, so we should remove the >> plugins from the main Quantum repository and require they be stored on their >> own. >> >> The first issue I worry about is Testing. Running the functional tests, and >> the plugin itself, requires access to soft and hardware. Some is open source >> and available to anyone, while some of these systems are proprietary. We >> can't expect the Core devs to have access to all of the proprietary >> equipment. If the core devs are not able to fully test the plugin, or even >> see the system it interfaces with, they can't be expected to fairly evaluate >> the plugin. This would lead to rubber stamping any commits that comes across >> Gerrit, and I think that would be bad for the Quantum codebase. A quick >> breeze through review does not help the plugin maintainers, its an extra >> hurdle without the benefit of review. >> >> Once the plugins are in Quantum, I'm worried about their maintenance. >> Keeping the plugins up to the quality expected of Quantum we will require >> developers proficient in the underlying system. If those people fall behind, >> or leave, what amount of regression will trigger the removal? We have a lot >> of changes planned for the near future, and requiring that every plugin be >> up to date will cause delays. It should be the job of the plugin's >> maintainer to keep the plugin up to date with Quantum, not the other way >> around. We can point out the repo of each plugin, but the plugin >> authors/maintainers should be responsible for documentation, maintenance, >> and compatibility. >> >> Thanks, >> Aaron Lee >> -- >> Mailing list: https://launchpad.net/~netstack >> Post to : netstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~netstack >> More help : https://help.launchpad.net/ListHelp > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
