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

Gary Kotton gkotton at vmware.com
Mon May 16 15:07:19 UTC 2016

Actually the breakage is not sue to Q_L3_ENABLED. It is due to
The Q_L3_ENABLED is something that each CI can configure depending on what
their supported mode is.
Until now this mean that L3 was supported by the plugin.

On 5/16/16, 5:26 PM, "Sean M. Collins" <sean at coreitpro.com> wrote:

>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.
>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,
>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
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list