[openstack-dev] [Neutron] Centralizing some config options will break many stadium projects
ihrachys at redhat.com
Tue Nov 1 15:58:52 UTC 2016
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
>>> 2) Fix it in order to provide folks with a recipe for how to address the
>> ^ the step depends on how far we want to go with the adoption. If it’s
>> 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
>> 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
> things that fwaas pulls from neutron config:
> 1.) FWaaS needs to know the L3 agent's agent_mode to differentiate the
> necessary depending on whether the L3 agent is running DVR or not, from
I believe we can live with maintaining is_dvr_enabled() function in
> 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
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.
More information about the OpenStack-dev