Hi, During the neutron refactor of DevStack, I made a conscious decision to take the Q_L3_ENABLED variable and change the default from False to True. Most DevStack installations will want to have L3 services enabled, so my thinking was, let's make it the default.
That broke some people last week, since they were relying on Q_L3_ENABLED to be False for their CI systems. My thinking was, really we should just be checking if the q-l3 service is enabled or not. https://review.openstack.org/#/c/315995/ That, in turn ended up breaking other people in a different way. So, the networking-generic-switch people were fixed, and the networking-midonet people became broken. As Yamamoto notes: >Actually, Q_L3_ENABLED=True and is_service_enabled q-l3 have quite >different meaning. The former means the plugin provides L3 >functionalities. The latter means Neutron L3 agent is enabled. MidoNet >provides L3 functionalities without using Neutron L3 agent. https://review.openstack.org/#/c/316660/1 I think this shows that the status-quo in neutron-legacy was untenable. Neutron-legacy is extremely brittle and things are very tightly coupled, with the slightest mistake or oversight breaking people. I think it's time to start pushing people in the direction that I pushed the OVN project - although I wish that I had planned things better instead of breaking everyone and causing a scramble. For that, I apologize. My suggestion for anyone who is broken right now - is to take a page from the OVN devstack plugin and start building up your own networking, rather than relying on any code in neutron-legacy. https://github.com/openstack/networking-ovn/commit/12e5bb646a4e0b43ef4c73bb627480a2dbb3e31c -- Sean M. Collins __________________________________________________________________________ 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