Open Stack

Nate Johnston <openstacknate at gmail.com> wrote:

> On Tue, Nov 01, 2016 at 01:17:25PM +0100, Ihar Hrachyshka wrote:
>> Armando M. <armamig at gmail.com> wrote:
>>> Slight variation, call it option 6:
>>>
>>> 1) Identify the most impacted (coupled) project affected by these  
>>> changes.
>>> 2) Fix it in order to provide folks with a recipe for how to address the
>>> breakages.
>>
>> ^ the step depends on how far we want to go with the adoption. If it’s  
>> just
>> changing import paths, then it will be easy but will give wrong signal to
>> subprojects that the whole practice of them piggy-backing on neutron  
>> options
>> is acceptable. On the other hand, we could help them get off the hook, by
>> working in scope of neutron-lib to expose whatever they *really* need (and
>> switch off neutron options completely where there is no clear semantic
>> requirement for the option value to be shared).
>>
>> While the latter path is not as easy, I would prefer it any time. It is in
>> line with the neutron-lib effort goal to decouple stadium subprojects from
>> neutron code base.
>
> Looking at neutron-fwaas as an example, it looks like there are two  
> significant
> things that fwaas pulls from neutron config:
>
> 1.) FWaaS needs to know the L3 agent's agent_mode to differentiate the  
> settings
> necessary depending on whether the L3 agent is running DVR or not, from
> neutron.conf.agent.l3.l3_config.

I believe we can live with maintaining is_dvr_enabled() function in  
neutron-lib.

> 2.) In unit tests use of load_paste_app to instantiate a WSGI app instance,
> from neutron.common.config.
>
> I'll think about the best way to handle the first case; the second is
> basically a two line convenience function that can be trivially copied  
> in-tree.

For the second one, some may even argue that if you need to run full API,  
it’s not a unit test anymore, and hence those test cases are better to live  
in corresponding -api/-scenario jobs.

Ihar