Difference between revisions of "NeutronSubteamCharters"
(→Sub Team Charters) |
|||
(9 intermediate revisions by 5 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 ==== | ||
− | + | * [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 === |
− | Design and implement | + | Design and implement VPN services and its associated functionality. |
==== Charter for Kilo ==== | ==== Charter for Kilo ==== | ||
+ | |||
+ | SSL-VPN | ||
+ | |||
+ | * barbican integration | ||
+ | |||
+ | Edge VPN | ||
+ | |||
* Define the model and the APIs which help provision edge VPN services. | * 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. | * Once the edge VPN has been provisioned, a tenant network (L2 or L3) is made part of that VPN. | ||
Line 81: | Line 93: | ||
Edge VPN APIs for MPLS VPN use case: https://review.openstack.org/#/c/136929 | Edge VPN APIs for MPLS VPN use case: https://review.openstack.org/#/c/136929 | ||
(others to be added shortly) | (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 === | === L3 Team === | ||
Line 92: | Line 106: | ||
==== Spec tracking ==== | ==== Spec tracking ==== | ||
− | * [ | + | * [Merged] [https://review.openstack.org/#/c/131535/ Kilo refactoring and restructuring the L3 agent] |
* [In Review] [https://review.openstack.org/#/c/97967/ Neutron Pluggable IPAM Blueprint] | * [In Review] [https://review.openstack.org/#/c/97967/ Neutron Pluggable IPAM Blueprint] | ||
* [In Review] [https://review.openstack.org/#/c/135771/ Add support for subnet allocation] | * [In Review] [https://review.openstack.org/#/c/135771/ Add support for subnet allocation] |
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.
Contents
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
- [In Review] LBaaS v2 object model
- [In Review] A10 Networks driver
- [Needs Re-proposing] Juno-incubator specs
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
- [L3 Agent] Add functional testing to L3 agent
- [L3 Agent] Pay down technical debt in the L3 agent by restructuring
- [IPAM] Support pluggable external IPAM
- [IPAM] Support automatic allocation of subnets with IPAM
- [Dynamic Routing] Integrate dynamic routing (with BGP implementation) with Neutron (not BGP/MPLS)
Spec tracking
- [Merged] Kilo refactoring and restructuring the L3 agent
- [In Review] Neutron Pluggable IPAM Blueprint
- [In Review] Add support for subnet allocation
- [In Review] BGP dynamic routing
- [In Review] Report HA router master
- [In Review] [Stretch Goal] Allow more flexible connection to external network
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