[openstack-dev] [neutron][devstack] Third party CI breakage around Q_L3_ENABLED

Sean M. Collins sean at coreitpro.com
Mon May 16 14:26:13 UTC 2016


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.


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.


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

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.


Sean M. Collins

More information about the OpenStack-dev mailing list