-----Original Message----- From: Erno Kuvaja <[email protected]> Reply: OpenStack Development Mailing List (not for usage questions) <[email protected]> Date: August 10, 2016 at 05:53:14 To: OpenStack Development Mailing List (not for usage questions) <[email protected]> Subject: Re: [openstack-dev] [requirements] History lesson please
> On Wed, Aug 10, 2016 at 9:27 AM, Thomas Goirand wrote: > > On 08/09/2016 08:33 PM, Ian Cordasco wrote: > >> > >> > >> -----Original Message----- > >> From: John Dickinson > >> Reply: OpenStack Development Mailing List (not for usage questions) > >> Date: August 9, 2016 at 13:17:08 > >> To: OpenStack Development Mailing List > >> Subject: Re: [openstack-dev] [requirements] History lesson please > >> > >>> I'd like to advocate for *not* raising minimum versions very often. Every > >>> time some > OpenStack > >>> project raises minimum versions, this change is propagated to all > >>> projects, and > that > >>> puts extra burden on anyone who is maintaining packages and dependencies > >>> in their > own > >>> deployment. If one project needs a new feature introduced in version 32, > >>> but another > >>> project claims compatibility with >=28, that's ok. There's no need for > >>> the second > project > >>> to raise the minimum version when there isn't a conflict. (This is the > >>> position I advocated > >>> for at the Austin summit.) > >>> > >>> Yes, I know that currently we don't test every possible version > >>> permutation. Yes, > I know > >>> that doing that is hard. I'm not ignoring that. > >> > >> Right. So with the current set-up, where these requirements are propogated > >> to every > project, how do projects express their own minimum version requirement? > >> > >> Let's assume someone is maintaining their own packages and dependencies. > >> If (for example) Glance requires a minimum version of Routes and Nova has > >> a minimum requirement newer than Glance's, they're not coinstallable > >> (which was the original goal of the requirements team). > > > > Not necessarily. Take for example Swift. It has lower requirements than > > other projects in OpenStack. Yet, Swift is fully co-installable with all > > other OpenStack projects. They just support lower versions than others. > > > This just makes lifecycle management total nightmare if different > project has different requirements within same release. Lets say we > have these projects Swift, X and Y that supports the lower versions, > now we decide to deploy Z to that same cloud but Z has higher > requirement than Swift, X and Y, so we need to upgrade that > requirement at minimum to that new level required by Z. > > Having 3 options here: > 1) We upgrade the requirement to the new level system wide and restart > Swift, X and Y to avoid any nasty surprises later down the line, which > is risky and disruptive by itself. > 2) We containerize/use venv for Z and provide the new version of the > dependency just for that. > 3) We deploy Z to it's own node. > > None of these are great user experience or contains significant risk > on production, makes version management total nightmare and gives us > more "happy" ops running OS. Having uniform requirements range, at > least we can be pretty confident that deploying new service from same > release will drop in and likely at least not break anything else if > the dependencies are within the range. Obviously we might hit to > version of dependency that has issue just with Z, but at least the > damage is contained to the new service. This is exactly what I was referring to when I said "co-installable". When I started learning the ways of OpenStack I had the same very naïve definition based on ranges and allowing projects to have different ranges. If a deployer is packaging things, all will be fine using a version for their services until they add that new service later which requires a higher version. So again, this leaves us with two options: - Raise minimum required versions very infrequently (as some seem to prefer) and explicitly prohibit use of new features in more recent versions of libraries - Coordinate minimum version bumps on a more consistent basis to allow projects to not duplicate code already present in the libraries they're attempting to use As a *developer* I'd prefer the latter. As a deployer using OpenStack-Ansible, either one is fine because OSA uses upper-constraints as recommended by the requirements team. That said, I recognize everyone deploys OpenStack just differently enough to cause the second option to be painful. Hence why I said "I'd like this to happen" but I never said it must. To be clear, I think the requirements work Tony is doing has the potential to make things worse for some subset of deployers/operators. -- Ian Cordasco __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
