Difference between revisions of "Network/Incubator"
(→What is it?)
(→Juno/Kilo Incubation Candidates)
|Line 80:||Line 80:|
===Juno/Kilo Incubation Candidates===
===Juno/Kilo Incubation Candidates===
* LBaaS v2
*Group Based Policy
* Group Based Policy
*BGP Dynamic Routing
* BGP Dynamic Routing
* VPNaaS (SSLVPN)
Revision as of 21:09, 26 August 2014
Note - This is a proposal currently under discussion, not an adopted part of the Neutron development process.
What is it?
The neutron-incubator is a proposed new git repo owned and managed by the Neutron core team to provide access to API extensions during the development process. The repo will facilitate rapid iteration while following OpenStack's review process, testing and community processes.
To provide a well known location within the community for proposed Neutron API extensions to mature prior to adoption into the integrated release.
Why a Seperate Repo?
Integrated releases are expected to be stable and the team is required to provide support for more than a year. These requirements place lots of pressure on the core team as the API must be absolutely perfect due to releases only occurring twice per year. Starting with the Grizzly cycle, the team has tried a variety of different workflows to improve quality of development and reduce the long-term technical debt. These workflows actually increased the burden on both the proposers and the core team by requiring a long series of fully functional patches. A separate repo will allow the extensions to mature in a reasonable manner for both the developers and reviewers.
The neutron-incubator project will not participate in the integrated release process. Releases will occur as features or significant changes merge. The released Alpha library will be published to PyPI for easy operator consumption. OpenStack Infra provides the tooling to make it easy to publish new updates. The ability to tag/release will provide the incubator a way to release new versions of APIs in development.
- Repository will be a collection of API Extensions that can be installed as a companion library for testing.
- APIs accepted for incubation should have targeted graduation within 2 cycles. (Note: If a feature needs longer, the feature is too immature to qualify for the incubator and should iterate in StackForge before reapplying later.)
- Extensions will loaded as any other Neutron Extension.
- The Incubator will initially follow the OpenStack rules of two +2s by cores before merging. This requirement is to ensure that a graduation reviews are not the first time the core team has examined the code.
- All proposed changes must pass the same HACKING rules as the main server project.
- All changes must pass Unit Test
- All changes must pass Functional Test
- All changes must not break Neutron's functional and unit testing
- All changes must not break Neutron's tempest testing
- A sub team may request the PTL or other designate publish an updated alpha library to the PyPI after key features merge to assist with testing and feedback.
- Features inside of Neutron project may not depend on incubation code
- API changes do not require a working implementation to merge. (NOTE: Implementation must work to graduate)
- Should be compatible with N and N-1 release (enabling operators to test against stable release)
- Any database migrations should be kept in a separate timeline and care should be taken to avoid breaking stable N to stable N+1 upgrades
Proposal for Inclusion
A sub-team within the Networking program may propose a new extension via the openstack-dev mailing list, at the weekly Neutron team meeting, or at a design summit session. If the core team feels that the proposed extension fits within the Networking programs mission, the API extension will be added to the neutron-incubator repository.
All extensions in the incubator shall be reviewed periodically to measure and provide feedback on progress.
An API extension or developing feature may exit the incubator by graduating, spinning out or being abandoned.
An extension will be eligible for graduation when the following requirements are met:
- Fits within the scope of Networking Program
- Mature API definition with no major planned backward incompatible changes
- API is consistent with the current stable API
- Open Source Reference Implementation
- Implementation consistent with Neutron architecture
- Full Unit Test Coverage
- Full Functional Test Coverage
- Developer Documentaton
- Supporting tests/docs ready for immediate proposal: (Note: link to commits in private trees is acceptable)
- Set of Tempest Tests (QA)
- API Documentation (Docs)
- User Documentation (Docs)
- Proposed CLI support (python-neutronclient)
- Horizon UI Support
- OpenStack SDK Support
- Proposed specs for concurrent merge work:
- Spec or documentation for how to deploy at scale with Open Source components.
- Spec for database migration work
- Must demonstrate one or both of the following:
In-tree scalable option and/or Multi-vendor support (driver or via compatibility layer). Note: Scalable OpenSource implementation option required.
- Stable third-party CI's in place for vendor drivers.
- If the API replaces another extension, a migration plan must be detailed and testable via Grenade test.
How to Graduate
A sub-team will send a request to the openstack-dev mailing list. The PTL will then schedule a discussion at a future weekly meeting for discussion. The discussion will seek to verify that the requirements have been met.
The Neutron team may elect to spin out an extension into a separate project (ie git repo, bug tracking, etc). Spin outs can occur when:
- The extension requires management by a dedicated core team with specific domain knowledge.
- The extension should be optional for deployers.
- The Networking Program may request that the TC allow the project to belong to the integrated release or to a new project outside the integrated release.
- Extension develops in a direction that does not fit within the scope of the Networking Program. (spun out to StackForge)
The core team may remove any incubated components in the event an API fails to gain traction, the developer support diminishes or at the request of the responsible subteam. The process will be initiated by proposing the code removal in gerrit and sending notice to the openstack-dev mailing list. The review shall not be approved until after 7 days to enable the core team time to consider the request and raise any concerns.
The current core team for Neutron will initially be core team for the incubator. In the future, the team may decide to add incubator only cores if the need arises.
Impact on Neutron
An additional CI job will be added to Neutron to ensure that incubation code is not broken by changes to main server project.
Juno/Kilo Incubation Candidates
- LBaaS v2
- Group Based Policy
- BGP Dynamic Routing
- VPNaaS (SSLVPN)