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[1]. 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. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
