Nate Johnston <[email protected]> wrote:
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.
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
