Open Stack

-----Original Message-----
From: Erno Kuvaja <ekuvaja at redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: August 10, 2016 at 05:53:14
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
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