[openstack-dev] [all] devstack changing to neutron by default RSN
sean at dague.net
Thu Aug 4 18:35:16 UTC 2016
One of the cycle goals in newton was to get devstack over to neutron by
default. Neutron is used by 90+% of our users, and nova network is
deprecated, and is not long for this world.
Because devstack is used by developers as well as by out test
infrastructure, the major stumbling block was coming up with a good
working default on a machine with only 1 interface, that doesn't leave
that interface in a totally broken state if you reboot the box (noting
that ovs changes are persistent by default, but brctl ones are not).
We think we've come up with a model that works. It's here -
https://review.openstack.org/#/c/350750/. And while it's surprisingly
short, it took a lot of thinking this one through to get there.
The crux of it is that we trust the value of PUBLIC_INTERFACE in a new
way on the neutron side. It is now unset by default (logic was changed
in n-net to keep things right there), and if set, then we assume you
really want neutron to manage this physical interface.
If not, that's cool. We're automatically creating a bridge interface
(with no physical interfaces in it) and managing that. For single node
testing this works fine. It passes all the tempest tests. The only
thing that's really weird in this setup is that because there is no
physical interface in that bridge, there is no path to the outside world
from guests. That means no package updates on them.
We address that with an iptables masq rule. It's a little cheaty pants,
however of the options we've got, it didn't seem so bad. (Note: if you
have a better option and are willing to get knee deep in solving it,
please do so. More contributors the better.)
It's going to take a bit for docs to all roll over here, but I think we
actually want this out sooner rather than later to find any other edge
cases that it introduces. There will be some bumpiness here. However,
being able to bring up a full neutron with only the 4 passwords
specified in config is quite nice.
1. actually 5 tests fail for unrelated reasons, which is that tempest
isn't probably excluding tests for services that aren't running because
it makes some assumptions on the gate config. That will be fixed soon.
More information about the OpenStack-dev