Open Stack

-----Original Message-----
From: Chris Friesen <chris.friesen at windriver.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: August 10, 2016 at 11:50:48
To: openstack-dev at lists.openstack.org <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [requirements] History lesson please

> On 08/10/2016 04:51 AM, Erno Kuvaja wrote:
> > On Wed, Aug 10, 2016 at 9:27 AM, Thomas Goirand wrote:
>  
> >> 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.
>  
> As Doug Hellman said earlier in the thread, they recommend to deployers/packages
> that they use the *highest* supported version as listed in upper-constraints.txt.  
>  
> In the case above, if the deployer had done this then bringing in Z would likely
> not have resulted in a need to upgrade any requirements.

I think the point that Erno and I have failed to mention is that often times OpenStack is not the only thing being deployed by an operator. So you have a range of supported versions in OpenStack + whatever else you may be deploying on that hardware. If the version of a dependency from something that is not OpenStack fits in one range but not another, you're making it quite hard to satisfy this. Granted, if both ranges are equal but still don't allow for the third party software constrant to be satisfied that's a separate problem, but at least there isn't confusion/disagreement in what the minimum supported version from the OpenStack projects is.

Even if that third-party software has a version that can be satisfied from both ranges, any operator worth their salt now has to go ahead and do the work to verify that version doesn't cause a different behaviour in anything else that's using the older version before deploying the new OpenStack service.

--  
Ian Cordasco