Jump to: navigation, search

Difference between revisions of "NeutronSubteamCharters"

(IPv6 subteam charter)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
'''DEPRECATED'''
 +
 +
Note, this page is deprecated.
 +
 
The number of sub teams in Neutron has grown to a crazy level. At some point in time, it made sense to have sub teams, but the sheer growth and lack of a clear charter for many of them has made their existence questionable. To solve this, sub teams should post a charter for each release explaining what they want to accomplish. The neutron-drivers team will then decide if it makes sense for a sub team to exist for that cycle. Ideally the sub teams own discovery process will lead to a decision on disbanding for a cycle in which there is no clear work direction and deliverable. An example of a functioning sub team which formed, accomplished work, and then disbanded was the Neutron DB sub team which worked for a few months during the Juno cycle.
 
The number of sub teams in Neutron has grown to a crazy level. At some point in time, it made sense to have sub teams, but the sheer growth and lack of a clear charter for many of them has made their existence questionable. To solve this, sub teams should post a charter for each release explaining what they want to accomplish. The neutron-drivers team will then decide if it makes sense for a sub team to exist for that cycle. Ideally the sub teams own discovery process will lead to a decision on disbanding for a cycle in which there is no clear work direction and deliverable. An example of a functioning sub team which formed, accomplished work, and then disbanded was the Neutron DB sub team which worked for a few months during the Juno cycle.
  
Line 68: Line 72:
 
Expected timeline and completion date is the release of Kilo.  
 
Expected timeline and completion date is the release of Kilo.  
 
==== Spec tracking ====
 
==== Spec tracking ====
To be re-proposed for Kilo soon:
+
* [In Review] [https://review.openstack.org/#/c/138205/ LBaaS v2 object model]
http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno-incubator
+
* [In Review] [https://review.openstack.org/#/c/138930/ A10 Networks driver]
 +
* [Needs Re-proposing] [http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno-incubator/ Juno-incubator specs]
  
 
=== VPNaaS Team ===
 
=== VPNaaS Team ===
Line 89: Line 94:
 
(others to be added shortly)
 
(others to be added shortly)
 
SSL-VPN (spec need to be pushed after barbican support functionaries)
 
SSL-VPN (spec need to be pushed after barbican support functionaries)
 +
BGPVPN interconnection : https://review.openstack.org/#/c/93329/
  
 
=== L3 Team ===
 
=== L3 Team ===
Line 123: Line 129:
 
==== Spec tracking ====
 
==== Spec tracking ====
 
VLAN support for DVR : https://review.openstack.org/#/c/131800
 
VLAN support for DVR : https://review.openstack.org/#/c/131800
 
=== IPv6 team ===
 
The IPv6 Neutron sub-team includes members on the Neutron community who wish to deploy Neutron in IPv6 networks, and bring feature parity between Neutron IPv4 & IPv6 networking
 
==== Charter for Kilo ====
 
* Focus heavily on fixing outstanding bugs, and fixing gaps in features that landed during the Juno development cycle, that have bugs when using IPv6.
 
* Complete specs that were introduced during the Juno cycle, and did not make the Juno release should have high priority because stakeholders have been very patient and continued to participate
 

Latest revision as of 17:11, 28 May 2015

DEPRECATED

Note, this page is deprecated.

The number of sub teams in Neutron has grown to a crazy level. At some point in time, it made sense to have sub teams, but the sheer growth and lack of a clear charter for many of them has made their existence questionable. To solve this, sub teams should post a charter for each release explaining what they want to accomplish. The neutron-drivers team will then decide if it makes sense for a sub team to exist for that cycle. Ideally the sub teams own discovery process will lead to a decision on disbanding for a cycle in which there is no clear work direction and deliverable. An example of a functioning sub team which formed, accomplished work, and then disbanded was the Neutron DB sub team which worked for a few months during the Juno cycle.

Sub Team Charters

The existing NeutronSubTeams should put their charters below for evaluation in next week's neutron-drivers meeting.

An example of this charter is below.

MySubTeam

This sub team does something really cool which everyone loves.

Charter for Kilo

Unicorns. With rainbows. So awesome.

End Goal (When Are you Done?)

Long lived sub-teams with no clear charter are bad. You should have a goal, a timeline, and a completion date in mind.

Spec tracking

Put approved specs here.

Advanced Services Team

Implement services and associated libraries that provide abstractions for advanced network functions beyond basic L2/L3 connectivity and forwarding.

Charter for Kilo

The Advanced Services' team coordinates the evolution of the advanced services' plugins and drivers (both, reference implementation, and vendor-specific). Authors and maintainers of all service plugins and drivers are encouraged to participate, along with everyone in the OpenStack community who has an interest in improving advanced networking services.

  • Coordinate with any Neutron-wide REST front-end and plugin API refactoring efforts
  • Coordinate with any Neutron-wide improvements in core DB layer (replace locking with optimistic/retry approaches, eliminate mix-ins,...)
  • Coordinate with advanced services' framework and split-related efforts
  • Participate in the L3 agent refactoring that impacts advanced services' drivers
  • (more)

Spec tracking

Adv Services split: https://review.openstack.org/136835 (others to be added shortly)

ML2 Team

The ML2 subteam coordinates the evolution of the ML2 Neutron core plugin. Authors and maintainers of all ML2 drivers are strongly encouraged to participate, along with everyone in the Neutron community who has an interest in improving ML2.

Charter for Kilo

  • Coordinate ML2 with Neutron REST front-end and plugin API refactoring efforts
  • Coordinate ML2 with improvements in core DB layer (replace locking with optimistic/retry approaches, eliminate mix-ins, ...)
  • Ensure removal of vendor drivers from the neutron repository does not jeopardize ML2's continued evolution and its ability to support heterogeneous deployments
  • Complete work started in Juno to support hierarchical network topologies
  • Coordinate with modular L2 agent task force efforts
  • Make progress on plugin-level support for back-end synchronization and error handling, potentially leveraging TaskFlow

Spec tracking

(to be added shortly)

FWaaS Team

Implement services and associated libraries that provide cloud-centric abstractions for a security feature set spanning traditional L2/3 firewalls to richer application-aware next-generation firewalls.

Charter for Kilo

The FWaaS Team coordinates the evolution of the FWaaS advanced service plugin and drivers (both, reference implementation, and vendor-specific). Authors and maintainers of all FWaaS service plugins and drivers are encouraged to participate, along with everyone in the OpenStack community who has an interest in improving the FWaaS component.

  • Coordinate FWaaS with any Neutron-wide REST front-end and plugin API refactoring efforts
  • Coordinate FWaaS with any Neutron-wide improvements in core DB layer (replace locking with optimistic/retry approaches, eliminate mix-ins,...)
  • Coordinate with the rest of the Advanced Services' team to support any common services' framework and split-related efforts
  • Evolve default firewall insertion model which attaches a firewall to all tenant routers, to one that can do this in a more granular fashion
  • Introduce Service Objects and Service Groups feature
  • Support addition of Vendor FWaaS plugins and drivers
  • Maintain and support FWaaS code-base from prior releases

Spec tracking

Service Groups and Objects: https://review.openstack.org/#/c/131596 (others to be added shortly)

LBaaS Team

Design, development, and merging of LBaaS v2 functionality.

Charter for Kilo

Merging changes to feature branch, agent-ified reference driver, CLI changes. With rainbows.

End Goal (When Are you Done?)

Exit criteria:

  • lbaas v2 code merged to master
  • all kilo drivers merged
  • no looming technical debt from the prior two goals

Expected timeline and completion date is the release of Kilo.

Spec tracking

VPNaaS Team

Design and implement VPN services and its associated functionality.

Charter for Kilo

SSL-VPN

  • barbican integration

Edge VPN

  • Define the model and the APIs which help provision edge VPN services.
  • Once the edge VPN has been provisioned, a tenant network (L2 or L3) is made part of that VPN.
  • Some of the common edge VPN services are L2 VPN (aka PWE or VPLS) and L3 VPN (BGP/MPLS VPN).

Spec tracking

Edge VPN APIs for MPLS VPN use case: https://review.openstack.org/#/c/136929 (others to be added shortly) SSL-VPN (spec need to be pushed after barbican support functionaries) BGPVPN interconnection : https://review.openstack.org/#/c/93329/

L3 Team

Develops and Maintains L3 related components of Neutron

Charter for Kilo

  1. [L3 Agent] Add functional testing to L3 agent
  2. [L3 Agent] Pay down technical debt in the L3 agent by restructuring
  3. [IPAM] Support pluggable external IPAM
  4. [IPAM] Support automatic allocation of subnets with IPAM
  5. [Dynamic Routing] Integrate dynamic routing (with BGP implementation) with Neutron (not BGP/MPLS)

Spec tracking

DVR Team

Address all the technical debts that the DVR team own to make DVR stable and work with other components of the Neutron.

Charter for Kilo

To address the technical debts from the DVR implementation

  • VLAN Support for DVR
  • VPNaaS Support for DVR
  • FWaaS Support for DVR East-West Traffic
  • L3 Agent Refactoring
  • Address issues with Agent Restart
  • IPv6 support and DVR compatability
  • L3 HA and DVR co-existance
  • Functional Testing and Scenario Testing for DVR
  • Multi-node Setup for DVR in gate
  • Documentation

Spec tracking

VLAN support for DVR : https://review.openstack.org/#/c/131800