Open Stack

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.
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.

--N.