Difference between revisions of "Network/Incubator"
(Neutron API Incubator)
m (→Why a Seperate Repo?)
|Line 6:||Line 6:|
=== Why a Seperate Repo? ===
=== Why a Seperate Repo? ===
Integrated releases are expected to be stable and the team is required to provide support for more than a year.
Integrated releases are expected to be stable and the team is required to provide support for more than a year. lots of pressure on the core team as the API must be absolutely perfect releases only 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 longterm technical debt. workflows actually the burden on both the proposers and the core team by requiring a long series of fully functional patches. separate repo will allow the extensions to mature in a reasonable manner for both the developers and reviewers.
=== Release Process ===
=== Release Process ===
Revision as of 19:08, 11 August 2014
What is it?
The neutron-incubator is a 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 initial follows 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 are kept in seperate timeline and care is 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 demostrate one or both following:
Intree scalable option and/or Multi-vendor support (driver or via compatability layer). Note: Scalable OpenSource implementation option required.
- Stable third-party CI's in place (For the open source version or the vendor versions?) 3rd party CI should only apply to drivers and plugins that are going to merge into master This is a list of graduation requirements; stable CI for vendor drivers should be on that checklist.
- 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 dicussion will seek to verify that the requirements have been met.
The Neutron team may elect to spin out an extension into a seperate 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 belong to the integrated release or 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 diminshes or the subteam requests. 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 test 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)