Now it breaks the kolla's master branch jobs. And have to remove the
and "neutron" in the upper-constraints.txt file. check[1][2].

i wanna know what's the correct way to install horizon develop
branch with upper-constraints.txt file?


On Thu, Mar 15, 2018 at 9:28 PM, Doug Hellmann <>

> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Jeffrey Zhang
OpenStack Development Mailing List (not for usage questions)

Reply via email to