Open Stack

Now it breaks the kolla's master branch jobs. And have to remove the
"horizon"
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?


[1] https://review.openstack.org/#/c/549456/4/docker/neutron/neutron-base/
Dockerfile.j2
[2] https://review.openstack.org/#/c/549456/4/docker/horizon/Dockerfile.j2



On Thu, Mar 15, 2018 at 9:28 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180316/cb7c98d5/attachment.html>