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
