Open Stack

Excerpts from Thomas Morin's message of 2018-03-15 10:15:38 +0100:
> Hi Doug,
> 
> Doug Hellmann, 2018-03-14 23:42:
> > We keep doing lots of infra-related work to make it "easy" to do
> >  when it comes to
> > managing dependencies.  There are three ways to address the issue
> > with horizon and neutron, and none of them involve adding features
> > to pbr.
> > 
> > 1. Things that are being used like libraries need to release like
> >    libraries. Real releases. With appropriate version numbers. So
> >    that other things that depend on them can express valid
> > dependencies.
> > 
> > 2. Extract the relevant code into libraries and release *those*.
> > 
> > 3. Things that are not stable enough to be treated as a library
> >    shouldn't be used that way. Move the things that use the
> > application
> >    code as library code back into the repo with the thing that they
> >    are tied to but that we don't want to (or can't) treat like a
> >    library.
> 
> What about the case where there is co-development of features across
> repos ? One specific case I have in mind is the Neutron stadium where

We do that all the time with the Oslo libraries. It's not as easy as
having everything in one repo, but we manage.

> we sometimes have features in neutron repo that are worked on as a pre-
> requisite for things that will be done in a neutron-* or networking-*
> project. Another is a case for instance where we need to add in project
> X a tempest test to validate the resolution of a bug for which the fix
> actually happened in project B (and where B is not a library).

If the tempest test can't live in B because it uses part of X, then I
think X and B are really one thing and you're doing more work than you
need to be doing to keep them in separate libraries.

> My intuition is that it is not illegitimate to expect this kind of
> development workflow to be feasible; but at the same time I read your
> suggestion above as meaning that it belongs to the real of "things we
> shouldn't be doing in the first place".  The only way I can reconcile

You read me correctly.

We install a bunch of components from source for integration tests
in devstack-gate because we want the final releases to work together.
But those things only interact via REST APIs, and don't import each
other.  The cases with neutron and horizon are different. Even the
*unit* tests of the add-ons require code from the "parent" app. That
indicates a level of coupling that is not being properly addressed by
the release model and code management practices for the parent apps.

> the two would be to conclude we should collapse all the module in
> neutron-*/networking-* into neutron, but doing that would have quite a
> lot of side effects (yes, this is an understatement).

That's not the only way to do it. The other way would be to properly
decompose the shared code into a library and then provide *stable
APIs* so code can be consumed by the add-on modules. That will make
evolving things a little more difficult because of the stability
requirement. So it's a trade off. I think the teams involved should
make that trade off (in one direction or another), instead of
building tools to continue to avoid dealing with it.

So let's start by examining the root of the problem: Why are the things
that need to import neutron/horizon not part of the neutron/horizon
repositories in the first place?

Doug