Excerpts from Thierry Carrez's message of 2016-04-19 11:48:06 +0200: > Thomas Goirand wrote: > > [...] > > From what I understand, the biggesgt problems you're trying to solve is > > that managing the global-reqs is really time consuming from the release > > team point of view, and especially its propagation to individual > > projects. There's IMO many things that we could do to improve the > > situation, which would be acceptable from the package maintainers point > > of view. > > It's not just the release team. The machinery around syncing global > requirements affects QA/Infra/Stable teams as well. > > > [...] > > On 04/18/2016 02:22 PM, Chris Dent wrote: > >> targeting an > >> all-in-one install seems only to serve the purposes of all-in-one rpm- > >> or deb-based installations. > > > > Though that's what most everyone consumes. Or are you proposing that we > > completely stop publishing OpenStack in distros? > > No, most people consume packages, but hopefully not as an all-in-one > installation (where you install everything on a single host). > > > Remember that in distros, there's only a single version of a library at > > any given time, at the exception of transitions (yes, in Red Hat it's > > technically possible to install multiple versions, but the policy > > strongly advocates against this). > > Depends on the distro. Gentoo for example lets you have multiple > versions of libraries installed at any given time. > > > [...] > > Please take a step back. Devstack and virtualenv are for development, > > not for production. That's not, and should not become, our target. > > All-in-one installations are also for development/test/demo, not for > production. That should not be our target either. > > > My point here is that we do have global dependencies for three reasons. > The first one is historic: because it facilitated all-in-one > devstack-based testing, I think we are past that one now. The second one > is operational: it encourages limiting the number of our dependencies > and the convergence across a common set of things. The third one is that > it facilitates the packaging work of old Linux distributions, which > generally have the limitation of only supporting one version of a given > library. > > I say "old", since with the advent of containers this limitation is > slowly going away. Ubuntu supports snappy packaging for container-based > packages, for example. They could totally package OpenStack that way if > they wanted. I expect in the future the one-version-of-lib-at-a-time > will more and more be seen as a self-imposed limitation and less as a > distribution axiom, and next-generation distros will appear that will > solve that limitation one way or another. > > That said, I still think we benefit from global requirements for the > second reason: it provides us a mechanism to encourage dependency > convergence. This is very important, as it limits the knowledge required > to operate OpenStack, facilitates contributors jumping from one code > base to another, provides a great checkpoint for licensing checks, and > reduce our overall security exposure by limiting the body of code we > rely on. If we dump global requirements we would have to replace it with > a lot of manual effort to push convergence overall.
Right, that's why I propose we keep the list of *names* as a way to check the packages we've approved in terms of not having lots of redundancy and for license compatibility. A new, looser, version of the current check run when a project's requirements.txt file is modified would be needed to look only at the name. 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
