← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1629133] Re: New neutron subnet pool support breaks multinode testing.

 

Reviewed:  https://review.openstack.org/388602
Committed: https://git.openstack.org/cgit/openstack/magnum/commit/?id=821bacc4a7f0b7a0f99d5b23da23375c3db41f64
Submitter: Jenkins
Branch:    master

commit 821bacc4a7f0b7a0f99d5b23da23375c3db41f64
Author: yatin <yatin.karel@xxxxxxxxxxxxxxxxxx>
Date:   Wed Oct 19 10:36:52 2016 +0000

    Revert "devstack: Fix neutron configuration to run in OSIC"
    
    This reverts commit 45f071e36eab4f3d20cacbc9cd610e536e1dd2b9.
    
    The Temporary fix can be reverted as devstack has released
    the fix in following patch:-
    https://review.openstack.org/398012
    
    Change-Id: I837f4925cf4c797bd1b02a7bf244ca5742159971
    Closes-Bug: #1628267
    Closes-Bug: #1629133


** Changed in: magnum
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1629133

Title:
  New neutron subnet pool support breaks multinode testing.

Status in networking-bgpvpn:
  New
Status in devstack:
  Fix Released
Status in Ironic:
  Fix Released
Status in ironic-python-agent:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  New
Status in neutron:
  Incomplete
Status in OpenStack DBaaS (Trove):
  In Progress

Bug description:
  The new subnet pool support in devstack breaks multinode testing bceause it results in the route for 10.0.0.0/8 being set to via br-ex when the host has interfaces that are actually on 10 nets and that is where we need the routes to go out. Multinode testing is affected because it uses these 10 net addresses to run the vxlan overlays between hosts.
  For many years devstack-gate has set FIXED_RANGE to ensure that the networks devstack uses do not interfere with the underlying test host's networking. However this setting was completely ignored when setting up the subnet pools.

  I think the correct way to fix this is to use a much smaller subnet
  pool range to avoid conflicting with every possible 10.0.0.0/8 network
  in the wild, possibly by defaulting to the existing FIXED_RANGE
  information. Using the existing information will help ensure that
  anyone with networks in 10.0.0.0/8 will continue to work if they have
  specified a range that doesn't conflict using this variable.

  In addition to this we need to clearly document what this new stuff in
  devstack does and how people can work around it should they conflict
  with the new defaults we end up choosing.

  I have proposed https://review.openstack.org/379543 which mostly works
  except it fails one tempest test that apparently depends on this new
  subnet pool stuff. Specifically the V6 range isn't large enough aiui.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bgpvpn/+bug/1629133/+subscriptions


References