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.ka...@nectechnologies.in>
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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
