[openstack-dev] [Neutron] Centralizing some config options will break many stadium projects
ihrachys at redhat.com
Tue Nov 1 12:17:25 UTC 2016
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
^ 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.
> 3) Use the patch and make it needed-by the neutron changes.
> 4) Evangelize patch 2 one more time on the ML.
> 5) We'll bring this up at the team meeting, for another form or record.
> 6) Wait another few days for projects to catch up.
> 7) Merge the patch in neutron.
> 8) We all move on.
More information about the OpenStack-dev