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 <d...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Regards, Jeffrey Zhang Blog: http://xcodest.me
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
