On Tue, Nov 01, 2016 at 01:17:25PM +0100, Ihar Hrachyshka wrote: > Armando M. <[email protected]> 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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
