Jump to: navigation, search

Meetings/TechnicalCommittee/Neutron Gap Coverage

This is the action plan to address neutron and nova-network parity gaps identified here.

Gap 0: DB Migrations in Neutron

Currently in neutron the db migrations include code that checks for features enabled at the time of migrations. This can put deployers in a bind when they attempt to turn on a neutron feature in the future, because the database migrations needed have been skipped. Bug: https://bugs.launchpad.net/neutron/+bug/1307344 explains in more detail.

  • Owner: markmcclain
  • Milestone: juno-2
  • Status: Complete

Gap 1: Tempest Testing

The list of Tempest tests which close this gap are here. These are being worked now. We're very close with most of these, we expect these to all close during Juno. The team is also actively triaging any new issues. We also have a Summit session around spreading the load for triaging gate issues and involving more Neutron team members in this area. One other area we're actively working on is functional testing. This is being driven by marun, and we expect in Juno to expand Neutron functional testing quite a bit. We have a Summit session on this as well.

  • Owner: mlavalle
  • Milestone: continuous work, closure at juno-3
  • Status: Full Tempest Job' voting for all projects w/o service enabled

Gap 2: Grenade Testing

Issues with current bugs being worked. Biggest issue right now: https://bugs.launchpad.net/neutron/+bug/1307344 We are actively working to solve the DB migration issues around service plugins which are the root of this issue.

  • Initially will include only Icehouse Neutron -> Juno Neutron. Later version will test Nova to Neutron path.
  • Owner: markmcclain
  • Milestone: juno-3

Gap 3: Neutron as the default in devstack

A patch exists for this now. Waiting on grenade being enabled to propose this patch to gerrit.

Gap 4: Missing API calls

This is being worked at the moment. Discussions have ensued on the bugs referenced at [1] around whether or not these APIs are needed. We will close on these in Juno.

  • Owner: markmcclain
  • Milestone: juno-1
  • Status: Complete

Gap 5: Neutron replacement for Nova multi-host

Nova-network provides a networking mode called multi-host. In this mode, every compute node serves as the network gateway for instances running locally. This provides horizontal scalability and HA for the networking component. Nova-network in its normal mode and Neutron historically only allow a single network node, which causes both scale and HA concerns. Neutron must provide functionality such that its L3 agent is no longer a single point of failure or scaling bottleneck. The Neutron team's answer to this is the DVR (distributed virtual router) project.

NOTE: need to discuss the fact that this requires OVS. link to ML thread:

Gap 6: nova-net to neutron migration

To fully deprecate nova-network, a migration to neutron needs to be put in place so nova-network users can successfully migrate from nova-network to neutron. From the TC perspective, the requirement is:

 In the case that a project has intentionally duplicated functionality of
 another project, or portion of a project, the new project must reach a level
 of functionality and maturity such that we are ready to deprecate the old
 code and remove it after a well defined deprecation cycle.  The deprecation
 plan agreed to by the PTLs of each affected project, including details for
 how users will be able to migrate from the old to the new, must be submitted
 to the TC for review as a part of the graduation review.

So, the primary requirements are:

  • Nova must be willing to deprecate nova-network.
  • The Neutron and Nova teams should work together to build a migration plan that both projects agree on.

This gap is focused on #2. The TC will review and officially bless the plan once it's deemed ready by both projects. The most recent discussion about the migration plan can be found here: http://lists.openstack.org/pipermail/openstack-dev/2014-August/041931.html

Gap 7: Document Open Source Options

One of the major concerns with users of nova-network switching to Neutron is around the overall quality of the open source backends available for Neutron. It is of critical importance that the community can be convinced that using neutron with an open source backend provides stability and scalability that is as good as using nova-network. The first goal for this gap is to document the scale limitations of the various open source Neutron backends. Additionally, there must be a plan for addressing known limitations that represent a parity gap with nova-network.

  • Owner: mestery
  • Milestone: juno-3

Additional actions

Design Summit Sessions Focused on Parity

The following sessions are all focused on the parity session and will be held in Atlanta:

  • nova-network parity: This will include a focus on the DVR work and on scale testing.
  • nova-network to neutron migration: A session solely focused on migrating from nova-network to neutron
  • neutron QA and testing: This session will cover Tempest and functional testing
  • neutron performance: This session will cover neutron performance issues
  • QA will have a grenade session where Neutron folks should show up (will try schedule outside of neutron slots)

Mid-Cycle Meetup

In addition to all of the above, we are also going to host a mid-cycle meeting focused solely on nova-network parity. This will likely be July 9-11 in Minnesota, and we hope to close as many gaps as possible during this time (in time for the juno-2 milestone)