Jump to: navigation, search

Difference between revisions of "Network/Incubator"

(Juno/Kilo Incubation Candidates)
m (Why a Seperate Repo?)
 
Line 7: Line 7:
 
To provide a well known location within the community for proposed Neutron API extensions to mature prior to adoption into the integrated release.
 
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? ===
+
=== Why a Separate 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.
 
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.
  

Latest revision as of 17:10, 29 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.

Mission

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 Separate 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.

Release Process

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 Guidelines

  • 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.

Periodic Review

All extensions in the incubator shall be reviewed periodically to measure and provide feedback on progress.

Exiting Incubation

An API extension or developing feature may exit the incubator by graduating, spinning out or being abandoned.

Graduation

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.

Spin Out

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)

Abandonment

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.

Core Team

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)
  • QoS