Open Stack

On Wed, Aug 10, 2016 at 9:27 AM, Thomas Goirand <zigo at debian.org> wrote:
> On 08/09/2016 08:33 PM, Ian Cordasco wrote:
>>
>>
>> -----Original Message-----
>> From: John Dickinson <me at not.mn>
>> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
>> Date: August 9, 2016 at 13:17:08
>> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
>> 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.

- Erno

>> If OpenStack drops the illusion of coinstallability that ends up being
>> fine. I don't think anyone wants to drop that though.
>
> Lucky, that's currently no illusion. It's a fact that currently,
> everything is co-installable. :)
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev