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
