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

Gary Kotton gkotton at vmware.com
Mon May 16 15:04:03 UTC 2016

I disagree. Sadly I approved the patch and it breaks all of the plugins
that have L3 support but do not require an agent.
Would it be possible that we unblock all of the plugins and try and work
towards a better solution.
The OVN example is good but that have a very small subset of tests.

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