[openstack-dev] [Neutron] Centralizing some config options will break many stadium projects
brandon.logan at RACKSPACE.COM
Tue Nov 1 23:01:27 UTC 2016
On Tue, 2016-11-01 at 13:17 +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
> options is acceptable. On the other hand, we could help them get off
> hook, by working in scope of neutron-lib to expose whatever they
> need (and switch off neutron options completely where there is no
> 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
> neutron code base.
Yeah this is pretty much the real question of this thread. How much
impact to subprojects is acceptable in getting to the 100% decoupled
> > 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
More information about the OpenStack-dev