Neutron Plugins and Drivers


 * TC approved list of Neutron projects - http://governance.openstack.org/reference/projects/neutron.html
 * More details about list of Neutron projects - http://docs.openstack.org/developer/neutron/#neutron-stadium
 * Point of contacts for Neutron areas and projects - http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#core-review-hierarchy
 * How to develop Neutron components - http://docs.openstack.org/developer/neutron/devref/contribute.html

Introduction
Ensuring release quality through proper testing is an important tenant of the OpenStack community and Neutron team wants to do our part. We are introducing changes below provide more visibility into the quality and stability of vendor plugin and driver code. The policies described here are in effect immediately.

Rationale
Code proposals for third party plugins have always presented a review challenge for the Neutron core team. In the early days, code was often proposed by core project contributors and our review process only validated whether the requirements were met for community coding style and unit testing. As Neutron has added new resources via extensions, it has become more difficult for Neutron reviewers to ensure the proposed code is functional. Many of the plugins and/or drivers require proprietary hardware and/or software to conduct such testing.

In addition to testing changes, the Neutron team is revising the requirements for the point of contact for third party code. The changes bring the written expectations for contacts in line with current practice.

Plugin and Driver Processes
Getting a plugin or driver merged upstream into Neutron allows you the benefit of being a part of the simultaneous release, and likely having your plugin or driver packaged with distributions which ship releases based on the simultaneous releases from upstream. However, this is not a "free ride", you should ideally be giving back more than you are taking by getting your code upstream. When you submit your code, you're putting a burden on the existing reviews and infrastructure. The same goes with subsequent bug fixes and backports to stable releases. Thus, you should have someone from your company or team reviewing other code upstream, participating in meetings, etc. The following is a list of requirements for inclusion of code upstream:
 * Code which passes review, has adequate unit tests, and passes pep8 guidelines.
 * A functioning CI system, which has been running successfully against your plugin/driver patches, and other patches as well.
 * Participation in Neutron meetings, IRC channels, and email lists.
 * A member of the plugin/driver team participating in code reviews of other upstream code.

Removal of Upstream Plugins or Drivers
If you fail to meet the criteria above, you risk having your plugin or driver removed from upstream. The core team will continue to evaluate third party CI systems to ensure they are running and correctly testing patches for third party plugins and drivers. If they fail to function, an email will be sent to the openstack-dev mailing list asking for the owner to fix this issue. Ideally, the owner will reply to the email thread, and will work with the Neutron and Infra teams to address the CI issue. If no reply is received or if adequate progress is not being made to address the issue within 2 weeks, a process to remove the plugin or driver from upstream will commence. To get your plugin or driver upstream after it has been removed will take a functioning third party CI system running for a month, correctly voting on changes upstream.

Point of Contact Requirements
Each third party plugin and/or driver shall designate a point of contact for each coordinated release cycle. The contact will serve as a liaison between the Neutron core team and the vendor or community supporting the plugin or driver. The contact shall:


 * Attend weekly Neutron team IRC meetings
 * Be an active reviewer and contributor
 * Be an active participant on openstack-dev mailing list
 * Assist the core team with triaging bugs specific to the plugin and/or driver
 * Ensure OpenStack development deadlines are properly communicated back to their company and/or community

Testing Requirements
https://wiki.openstack.org/wiki/NeutronThirdPartyTesting

Existing Plugin and Drivers
Plugins and drivers currently in the Neutron project repository will be given a grace period until the Icehouse-2 milestone to implement external third party testing. At that time, the Neutron team will release a list of the compatible plugins and drivers (i.e. those that meet the testing requirements). Plugins and drivers that do not have external testing will be deprecated at the Icehouse release and will be candidates for removal when the J-release cycle opens.

The page ThirdPartySystems gathers information about all third party CI system (including Neutron related).