Re: [openstack-dev] [requirements] History lesson please

[Clay Gerrard]

On Tue, Aug 9, 2016 at 11:54 AM, Hayes, Graham  wrote:

>
> It might not make a difference to deployers / packagers who only deploy
> one project from OpenStack, but they are in the minority - having a
> known good minimum for requirements helps deployers who have multiple
> services to deploy.
>

I'm not sure how true that is.  I think in the largest cloud organizations
the different cloud services are managed by different teams that are
working hard to deliver a stable, well tested, continuously deployed,
*service* that is always rapidly approaching tracking master.

In these organizations it may be that the team ultimately fully responsible
for the successful quality and availability of just a *single* service -
doesn't need to *test* and deploy with the next new minor version of routes
(if their requirements don't mandate it) just to get out the next bug fix -
because they're not *trying* to co-install *all* the services onto a
homogenous fleet?

Even if these kind of teams were let's say... a non-trivial minority... I
don't think their needs should be *ignored*.  I agree with John & Thomas
and am excited to hear about Tony's effort.

 -Clay
__
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

Re: [openstack-dev] [requirements] History lesson please

[Ian Cordasco]

-Original Message-
From: Chris Friesen <chris.frie...@windriver.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 10, 2016 at 11:50:48
To: openstack-dev@lists.openstack.org <openstack-dev@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


__
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

Re: [openstack-dev] [requirements] History lesson please

[Chris Friesen]

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.


Chris

__
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

Re: [openstack-dev] [requirements] History lesson please

[Matthew Thode]

On 08/10/2016 07:30 AM, Ian Cordasco wrote:
> 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

Any change we make has the potential to make things worse for some subset :P

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [requirements] History lesson please

[Ian Cordasco]

 

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

Re: [openstack-dev] [requirements] History lesson please

[Erno Kuvaja]

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

__
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

Re: [openstack-dev] [requirements] History lesson please

[Thomas Goirand]

On 08/09/2016 09:09 PM, Doug Hellmann wrote:
> We've tried to be consistent in telling packagers to use the
> versions listed in upper-constraints.txt unless there is an absolute
> need to use something else. Those are the versions we test, and
> therefore the versions we claim to support right now.

Which I've been trying to do as much as possible. It's easy to do so for
OpenStack components (ie: OpenStack libs, Oslo libs, clients, etc.).
It's sometimes harder for 3rd parties which are also used by
non-OpenStack related software within the distribution (for example,
Django, SQLAlchemy, etc.). For these, from a distro perspective, the
wider range of version the better.

Cheers,

Thomas Goirand (zigo)


__
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

Re: [openstack-dev] [requirements] History lesson please

[Thomas Goirand]

On 08/09/2016 08:54 PM, Hayes, Graham wrote:
> But then packagers are going to have to do the work anyway, as it will
> have in effect raised the minimum version of routes for Glance, and thus
> need a new package.

Which isn't a problem. It's perfectly ok to upload a new upstream
release of a package, because only a single component of OpenStack needs
that new version. In fact, this happened many times in the past already.

> It might not make a difference to deployers / packagers who only deploy
> one project from OpenStack, but they are in the minority - having a
> known good minimum for requirements helps deployers who have multiple
> services to deploy.

The thing is, currently, it's one single concept, which is the issue.
The global-requirements.txt should be expressing whatever is the lowest
possible on the full scope of OpenStack (which it currently does). But I
don't agree that every project needs to be dumb and increase lower
bounds when they in fact don't need to do so. IMO they should follow
what Swift does: test lower bounds. Currently John does this manually.
In an ideal world, every project would be individually tested for it,
automatically.

Cheers,

Thomas Goirand (zigo)


__
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

Re: [openstack-dev] [requirements] History lesson please

[Thomas Goirand]

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

> 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] History lesson please

[Thomas Goirand]

On 08/09/2016 08:25 PM, Julien Danjou wrote:
> On Tue, Aug 09 2016, John Dickinson wrote:
> 
>> 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.)
> 
> Amen to that.

+1


__
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

Re: [openstack-dev] [requirements] History lesson please

[Tony Breeds]

On Tue, Aug 09, 2016 at 03:14:43PM -0400, Davanum Srinivas wrote:
> +1 for volunteers to step up.

I'll do it and I have a *very* basic prototype done.  It wont be in Newton
though.  Having said that if there is another volenteer I'm happy to work with
them or free up time :)

Yours Tony.

PS: Replying to the *esy* parts of this thread pre-coffee ;P


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [requirements] History lesson please

[Davanum Srinivas]

+1 for volunteers to step up.

-- Dims

On Tue, Aug 9, 2016 at 3:07 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from John Dickinson's message of 2016-08-09 11:14:57 -0700:
>> 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.
>>
>> --John
>
> As we said at the summit, when someone changes the requirements sync job
> to deal with overlapping and compatible ranges, this will be fine. We
> don't currently have anyone working on that, but since we agreed we
> would do it if there are any volunteers they should talk with the
> requirements team about how to get started.
>
> In the mean time, projects following the global requirements process
> are still expected to sync the patches created by the bot.
>
> Doug
>
>>
>> On 9 Aug 2016, at 9:24, Ian Cordasco wrote:
>>
>> >
>> >
>> > -Original Message-
>> > From: Sean Dague <s...@dague.net>
>> > Reply: OpenStack Development Mailing List (not for usage questions) 
>> > <openstack-dev@lists.openstack.org>
>> > Date: August 9, 2016 at 11:21:47
>> > To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
>> > Subject:  Re: [openstack-dev] [requirements] History lesson please
>> >
>> >> On 08/09/2016 11:25 AM, Matthew Thode wrote:
>> >>> On 08/09/2016 10:22 AM, Ian Cordasco wrote:
>> >>>> -Original Message-
>> >>>> From: Matthew Thode
>> >>>> Reply: prometheanf...@gentoo.org , OpenStack Development
>> >> Mailing List (not for usage questions)
>> >>>> Date: August 9, 2016 at 09:53:53
>> >>>> To: openstack-dev@lists.openstack.org
>> >>>> Subject: Re: [openstack-dev] [requirements] History lesson please
>> >>>>
>> >>>>> One of the things on our todo list is to test the 'lower-constraints' 
>> >>>>> to
>> >>>>> make sure they still work with the head of branch.
>> >>>>
>> >>>> That's not sufficient. You need to find versions in between the lowest 
>> >>>> tested version
>> >> and the current version to also make sure you don't end up with breakage. 
>> >> You might have
>> >> somepackage that has a lower version of 2.0.1 and a current constraint of 
>> >> 2.12.3. You
>> >> might even have a blacklist of versions in between those two versions, 
>> >> but you still need
>> >> other versions to ensure that things in between those continue to work.
>> >>>>
>> >>>> THe tiniest of accidental incompatibilities can cause some of the most 
>> >>>> bizarre bugs.
>> >>>>
>> >>>> --
>> >>>> Ian Cordasco
>> >>>>
>> >>>
>> >>> I'm aware of this, but this would be a good start.
>> >>
>> >> And, more importantly, assuming that testing is only valid if it covers
>> >> every scenario, sets the bar at entirely the wrong place.
>> >>
>> >> A lower bound test would eliminate some of the worst fiction we've got.
>> >> Testing is never 100%. With a complex system like OpenStack, it's
>> >> probably not even 1% (of configs matrix for sure). But picking some
>> >> interesting representative scenarios and seeing that it's not completely
>> >> busted is worth while.
>> >
>> > Right. I'm not advocating for testing every released version of a 
>> > dependency. In general, it's good to test versions that have *triggered* 
>> > changes though. If upgrading from 2.3.0 to 2.4.1 caused you to need to fix 
>> > something, test something earlier than 2.4.1, and 2.4.1, and then 
>> > something later. That's what I'm advocating for.
>> >
>> > --
>> > Ian Cordasco
>> >
>> >
>> > __
>> > 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
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

Re: [openstack-dev] [requirements] History lesson please

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-08-09 18:54:57 +:
> On 09/08/2016 19:41, John Dickinson wrote:
> >
> >
> > On 9 Aug 2016, at 11:33, Ian Cordasco wrote:
> >
> >>
> >>
> >> -Original Message-
> >> From: John Dickinson <m...@not.mn>
> >> Reply: OpenStack Development Mailing List (not for usage questions) 
> >> <openstack-dev@lists.openstack.org>
> >> Date: August 9, 2016 at 13:17:08
> >> To: OpenStack Development Mailing List <openstack-dev@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). What you're asking 
> >> for ends up being "Don't rely on new features in a dependency". If 
> >> OpenStack drops the illusion of coinstallability that ends up being fine. 
> >> I don't think anyone wants to drop that though.
> >
> > In that case, they are still co-installable, because the nova minimum 
> > satisfies both.
> 
> But then packagers are going to have to do the work anyway, as it will
> have in effect raised the minimum version of routes for Glance, and thus
> need a new package.
> 
> It might not make a difference to deployers / packagers who only deploy
> one project from OpenStack, but they are in the minority - having a
> known good minimum for requirements helps deployers who have multiple
> services to deploy.

We've tried to be consistent in telling packagers to use the
versions listed in upper-constraints.txt unless there is an absolute
need to use something else. Those are the versions we test, and
therefore the versions we claim to support right now.

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

Re: [openstack-dev] [requirements] History lesson please

[Doug Hellmann]

Excerpts from John Dickinson's message of 2016-08-09 11:14:57 -0700:
> 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.
> 
> --John

As we said at the summit, when someone changes the requirements sync job
to deal with overlapping and compatible ranges, this will be fine. We
don't currently have anyone working on that, but since we agreed we
would do it if there are any volunteers they should talk with the
requirements team about how to get started.

In the mean time, projects following the global requirements process
are still expected to sync the patches created by the bot.

Doug

> 
> On 9 Aug 2016, at 9:24, Ian Cordasco wrote:
> 
> >  
> >
> > -Original Message-
> > From: Sean Dague <s...@dague.net>
> > Reply: OpenStack Development Mailing List (not for usage questions) 
> > <openstack-dev@lists.openstack.org>
> > Date: August 9, 2016 at 11:21:47
> > To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
> > Subject:  Re: [openstack-dev] [requirements] History lesson please
> >
> >> On 08/09/2016 11:25 AM, Matthew Thode wrote:
> >>> On 08/09/2016 10:22 AM, Ian Cordasco wrote:
> >>>> -Original Message-
> >>>> From: Matthew Thode
> >>>> Reply: prometheanf...@gentoo.org , OpenStack Development
> >> Mailing List (not for usage questions)
> >>>> Date: August 9, 2016 at 09:53:53
> >>>> To: openstack-dev@lists.openstack.org
> >>>> Subject: Re: [openstack-dev] [requirements] History lesson please
> >>>>
> >>>>> One of the things on our todo list is to test the 'lower-constraints' to
> >>>>> make sure they still work with the head of branch.
> >>>>
> >>>> That's not sufficient. You need to find versions in between the lowest 
> >>>> tested version
> >> and the current version to also make sure you don't end up with breakage. 
> >> You might have
> >> somepackage that has a lower version of 2.0.1 and a current constraint of 
> >> 2.12.3. You
> >> might even have a blacklist of versions in between those two versions, but 
> >> you still need
> >> other versions to ensure that things in between those continue to work.
> >>>>
> >>>> THe tiniest of accidental incompatibilities can cause some of the most 
> >>>> bizarre bugs.
> >>>>
> >>>> --
> >>>> Ian Cordasco
> >>>>
> >>>
> >>> I'm aware of this, but this would be a good start.
> >>
> >> And, more importantly, assuming that testing is only valid if it covers
> >> every scenario, sets the bar at entirely the wrong place.
> >>
> >> A lower bound test would eliminate some of the worst fiction we've got.
> >> Testing is never 100%. With a complex system like OpenStack, it's
> >> probably not even 1% (of configs matrix for sure). But picking some
> >> interesting representative scenarios and seeing that it's not completely
> >> busted is worth while.
> >
> > Right. I'm not advocating for testing every released version of a 
> > dependency. In general, it's good to test versions that have *triggered* 
> > changes though. If upgrading from 2.3.0 to 2.4.1 caused you to need to fix 
> > something, test something earlier than 2.4.1, and 2.4.1, and then something 
> > later. That's what I'm advocating for.
> >
> > --
> > Ian Cordasco
> >
> >
> > __
> > 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

__
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

Re: [openstack-dev] [requirements] History lesson please

[Matthew Thode]

On 08/09/2016 01:37 PM, John Dickinson wrote:
> In that case, they are still co-installable, because the nova minimum 
> satisfies both.

The requirements project currently advocates the use of
upper-requirements.txt as what is targeted for packagers.  This is
what's tested.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [requirements] History lesson please

[Hayes, Graham]

On 09/08/2016 19:41, John Dickinson wrote:
>
>
> On 9 Aug 2016, at 11:33, Ian Cordasco wrote:
>
>>
>>
>> -Original Message-
>> From: John Dickinson <m...@not.mn>
>> Reply: OpenStack Development Mailing List (not for usage questions) 
>> <openstack-dev@lists.openstack.org>
>> Date: August 9, 2016 at 13:17:08
>> To: OpenStack Development Mailing List <openstack-dev@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). What you're asking for ends 
>> up being "Don't rely on new features in a dependency". If OpenStack drops 
>> the illusion of coinstallability that ends up being fine. I don't think 
>> anyone wants to drop that though.
>
> In that case, they are still co-installable, because the nova minimum 
> satisfies both.

But then packagers are going to have to do the work anyway, as it will
have in effect raised the minimum version of routes for Glance, and thus
need a new package.

It might not make a difference to deployers / packagers who only deploy
one project from OpenStack, but they are in the minority - having a
known good minimum for requirements helps deployers who have multiple
services to deploy.

>
>>
>> --
>> Ian Cordasco


__
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

Re: [openstack-dev] [requirements] History lesson please

[John Dickinson]

On 9 Aug 2016, at 11:33, Ian Cordasco wrote:

>  
>
> -Original Message-
> From: John Dickinson <m...@not.mn>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: August 9, 2016 at 13:17:08
> To: OpenStack Development Mailing List <openstack-dev@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). What you're asking for ends up 
> being "Don't rely on new features in a dependency". If OpenStack drops the 
> illusion of coinstallability that ends up being fine. I don't think anyone 
> wants to drop that though.

In that case, they are still co-installable, because the nova minimum satisfies 
both.

>
> --
> Ian Cordasco


signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [requirements] History lesson please

[Ian Cordasco]

 

-Original Message-
From: John Dickinson <m...@not.mn>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 9, 2016 at 13:17:08
To: OpenStack Development Mailing List <openstack-dev@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). What you're asking for ends up 
being "Don't rely on new features in a dependency". If OpenStack drops the 
illusion of coinstallability that ends up being fine. I don't think anyone 
wants to drop that though.

--  
Ian Cordasco


__
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

Re: [openstack-dev] [requirements] History lesson please

[Davanum Srinivas]

fyi, Just so you all know. It's upper-constraints.txt. Note the word "upper" :)

-- Dims

On Tue, Aug 9, 2016 at 2:25 PM, Julien Danjou  wrote:
> On Tue, Aug 09 2016, John Dickinson wrote:
>
>> 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.)
>
> Amen to that.
>
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

Re: [openstack-dev] [requirements] History lesson please

[Julien Danjou]

On Tue, Aug 09 2016, John Dickinson wrote:

> 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.)

Amen to that.

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [requirements] History lesson please

[John Dickinson]

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.

--John




On 9 Aug 2016, at 9:24, Ian Cordasco wrote:

>  
>
> -Original Message-
> From: Sean Dague <s...@dague.net>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: August 9, 2016 at 11:21:47
> To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [requirements] History lesson please
>
>> On 08/09/2016 11:25 AM, Matthew Thode wrote:
>>> On 08/09/2016 10:22 AM, Ian Cordasco wrote:
>>>> -Original Message-
>>>> From: Matthew Thode
>>>> Reply: prometheanf...@gentoo.org , OpenStack Development
>> Mailing List (not for usage questions)
>>>> Date: August 9, 2016 at 09:53:53
>>>> To: openstack-dev@lists.openstack.org
>>>> Subject: Re: [openstack-dev] [requirements] History lesson please
>>>>
>>>>> One of the things on our todo list is to test the 'lower-constraints' to
>>>>> make sure they still work with the head of branch.
>>>>
>>>> That's not sufficient. You need to find versions in between the lowest 
>>>> tested version
>> and the current version to also make sure you don't end up with breakage. 
>> You might have
>> somepackage that has a lower version of 2.0.1 and a current constraint of 
>> 2.12.3. You
>> might even have a blacklist of versions in between those two versions, but 
>> you still need
>> other versions to ensure that things in between those continue to work.
>>>>
>>>> THe tiniest of accidental incompatibilities can cause some of the most 
>>>> bizarre bugs.
>>>>
>>>> --
>>>> Ian Cordasco
>>>>
>>>
>>> I'm aware of this, but this would be a good start.
>>
>> And, more importantly, assuming that testing is only valid if it covers
>> every scenario, sets the bar at entirely the wrong place.
>>
>> A lower bound test would eliminate some of the worst fiction we've got.
>> Testing is never 100%. With a complex system like OpenStack, it's
>> probably not even 1% (of configs matrix for sure). But picking some
>> interesting representative scenarios and seeing that it's not completely
>> busted is worth while.
>
> Right. I'm not advocating for testing every released version of a dependency. 
> In general, it's good to test versions that have *triggered* changes though. 
> If upgrading from 2.3.0 to 2.4.1 caused you to need to fix something, test 
> something earlier than 2.4.1, and 2.4.1, and then something later. That's 
> what I'm advocating for.
>
> --
> Ian Cordasco
>
>
> __
> 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


signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [requirements] History lesson please

[Ian Cordasco]

 

-Original Message-
From: Sean Dague <s...@dague.net>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 9, 2016 at 11:21:47
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [requirements] History lesson please

> On 08/09/2016 11:25 AM, Matthew Thode wrote:
> > On 08/09/2016 10:22 AM, Ian Cordasco wrote:
> >> -Original Message-
> >> From: Matthew Thode  
> >> Reply: prometheanf...@gentoo.org , OpenStack Development  
> Mailing List (not for usage questions)  
> >> Date: August 9, 2016 at 09:53:53
> >> To: openstack-dev@lists.openstack.org  
> >> Subject: Re: [openstack-dev] [requirements] History lesson please
> >>
> >>> One of the things on our todo list is to test the 'lower-constraints' to
> >>> make sure they still work with the head of branch.
> >>
> >> That's not sufficient. You need to find versions in between the lowest 
> >> tested version  
> and the current version to also make sure you don't end up with breakage. You 
> might have  
> somepackage that has a lower version of 2.0.1 and a current constraint of 
> 2.12.3. You  
> might even have a blacklist of versions in between those two versions, but 
> you still need  
> other versions to ensure that things in between those continue to work.
> >>
> >> THe tiniest of accidental incompatibilities can cause some of the most 
> >> bizarre bugs.  
> >>
> >> --
> >> Ian Cordasco
> >>
> >
> > I'm aware of this, but this would be a good start.
>  
> And, more importantly, assuming that testing is only valid if it covers
> every scenario, sets the bar at entirely the wrong place.
>  
> A lower bound test would eliminate some of the worst fiction we've got.
> Testing is never 100%. With a complex system like OpenStack, it's
> probably not even 1% (of configs matrix for sure). But picking some
> interesting representative scenarios and seeing that it's not completely
> busted is worth while.

Right. I'm not advocating for testing every released version of a dependency. 
In general, it's good to test versions that have *triggered* changes though. If 
upgrading from 2.3.0 to 2.4.1 caused you to need to fix something, test 
something earlier than 2.4.1, and 2.4.1, and then something later. That's what 
I'm advocating for.

--  
Ian Cordasco


__
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

Re: [openstack-dev] [requirements] History lesson please

[Sean Dague]

On 08/09/2016 11:25 AM, Matthew Thode wrote:
> On 08/09/2016 10:22 AM, Ian Cordasco wrote:
>> -Original Message-
>> From: Matthew Thode <prometheanf...@gentoo.org>
>> Reply: prometheanf...@gentoo.org <prometheanf...@gentoo.org>, OpenStack 
>> Development Mailing List (not for usage questions) 
>> <openstack-dev@lists.openstack.org>
>> Date: August 9, 2016 at 09:53:53
>> To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
>> Subject:  Re: [openstack-dev] [requirements] History lesson please
>>
>>> One of the things on our todo list is to test the 'lower-constraints' to
>>> make sure they still work with the head of branch.
>>
>> That's not sufficient. You need to find versions in between the lowest 
>> tested version and the current version to also make sure you don't end up 
>> with breakage. You might have somepackage that has a lower version of 2.0.1 
>> and a current constraint of 2.12.3. You might even have a blacklist of 
>> versions in between those two versions, but you still need other versions to 
>> ensure that things in between those continue to work.
>>
>> THe tiniest of accidental incompatibilities can cause some of the most 
>> bizarre bugs.
>>
>> --  
>> Ian Cordasco
>>
> 
> I'm aware of this, but this would be a good start.

And, more importantly, assuming that testing is only valid if it covers
every scenario, sets the bar at entirely the wrong place.

A lower bound test would eliminate some of the worst fiction we've got.
Testing is never 100%. With a complex system like OpenStack, it's
probably not even 1% (of configs matrix for sure). But picking some
interesting representative scenarios and seeing that it's not completely
busted is worth while.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [requirements] History lesson please

[Matthew Thode]

On 08/09/2016 10:22 AM, Ian Cordasco wrote:
> -Original Message-
> From: Matthew Thode <prometheanf...@gentoo.org>
> Reply: prometheanf...@gentoo.org <prometheanf...@gentoo.org>, OpenStack 
> Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: August 9, 2016 at 09:53:53
> To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [requirements] History lesson please
> 
>> One of the things on our todo list is to test the 'lower-constraints' to
>> make sure they still work with the head of branch.
> 
> That's not sufficient. You need to find versions in between the lowest tested 
> version and the current version to also make sure you don't end up with 
> breakage. You might have somepackage that has a lower version of 2.0.1 and a 
> current constraint of 2.12.3. You might even have a blacklist of versions in 
> between those two versions, but you still need other versions to ensure that 
> things in between those continue to work.
> 
> THe tiniest of accidental incompatibilities can cause some of the most 
> bizarre bugs.
> 
> --  
> Ian Cordasco
> 

I'm aware of this, but this would be a good start.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [requirements] History lesson please

[Ian Cordasco]

-Original Message-
From: Matthew Thode <prometheanf...@gentoo.org>
Reply: prometheanf...@gentoo.org <prometheanf...@gentoo.org>, OpenStack 
Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 9, 2016 at 09:53:53
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [requirements] History lesson please

> One of the things on our todo list is to test the 'lower-constraints' to
> make sure they still work with the head of branch.

That's not sufficient. You need to find versions in between the lowest tested 
version and the current version to also make sure you don't end up with 
breakage. You might have somepackage that has a lower version of 2.0.1 and a 
current constraint of 2.12.3. You might even have a blacklist of versions in 
between those two versions, but you still need other versions to ensure that 
things in between those continue to work.

THe tiniest of accidental incompatibilities can cause some of the most bizarre 
bugs.

--  
Ian Cordasco


__
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

Re: [openstack-dev] [requirements] History lesson please

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2016-08-09 16:38:35 +1000:
> Hi all,
> I guess this is aimed at the long term requirements team members.
> 
> The current policy for approving requirements[1] bumps contains the following 
> text:
> 
> Changes to update the minimum version of a library developed by the
> OpenStack community can be approved by one reviewer, as long as the
> constraints are correct and the tests pass.
> 
> Perhaps I'm a little risk adverse but this seems a little strange to me.  Can
> folks that know more about how this came about help me understand why that is?
> 
> Yours Tony.
> 
> [1] 
> https://github.com/openstack/requirements/blob/master/README.rst#for-upgrading-requirements-versions

It's limited to libraries we maintain, so that lowers the risk some. But
as Sean pointed out, it's riskier to assume the older releases continue
to work because typically a request to raise a minimum version means an
app wants to depend on a feature that appears in the newer version.

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

Re: [openstack-dev] [requirements] History lesson please

[Matthew Thode]

On 08/09/2016 09:25 AM, Ian Cordasco wrote:
>  
> 
> -Original Message-
> From: Sean Dague <s...@dague.net>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: August 9, 2016 at 05:44:55
> To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [requirements] History lesson please
> 
>> On 08/09/2016 02:38 AM, Tony Breeds wrote:
>>> Hi all,
>>> I guess this is aimed at the long term requirements team members.
>>>
>>> The current policy for approving requirements[1] bumps contains the 
>>> following text:  
>>>
>>> Changes to update the minimum version of a library developed by the
>>> OpenStack community can be approved by one reviewer, as long as the
>>> constraints are correct and the tests pass.
>>>
>>> Perhaps I'm a little risk adverse but this seems a little strange to me. Can
>>> folks that know more about how this came about help me understand why that 
>>> is?
>>>
>>> Yours Tony.
>>>
>>> [1] 
>>> https://github.com/openstack/requirements/blob/master/README.rst#for-upgrading-requirements-versions
>>>   
>>  
>> With constraints, the requirements minimum bump is pretty low risk. Very
>> little of our jobs are impacted by it.
>>  
>> It's in many ways more risking to leave minimums where they are and bump
>> constraints, because the minimums could be lying that they still work at
>> the lower level.
>>  
>> -Sean
> 
> I maintain a few libraries outside of OpenStack that have generous lower 
> limits and testing them is resource intensive both as a developer and in 
> continuous integration. I'd love to see OpenStack be *more* aggressive about 
> the oldest version it supports because in most cases I severely distrust the 
> version ranges we use. I do recognize, however, that we have to coordinate 
> with some distributions that will not update their packaged versions (which 
> are often an old version number with security patches poorly cherry-picked). 
> So you may need to coordinate with them before bumping version minimums as 
> well.
> 
> --  
> Ian Cordasco
> 
> 
> __
> 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
> 

One of the things on our todo list is to test the 'lower-constraints' to
make sure they still work with the head of branch.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [requirements] History lesson please

[Ian Cordasco]

 

-Original Message-
From: Sean Dague <s...@dague.net>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: August 9, 2016 at 05:44:55
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [requirements] History lesson please

> On 08/09/2016 02:38 AM, Tony Breeds wrote:
> > Hi all,
> > I guess this is aimed at the long term requirements team members.
> >
> > The current policy for approving requirements[1] bumps contains the 
> > following text:  
> >
> > Changes to update the minimum version of a library developed by the
> > OpenStack community can be approved by one reviewer, as long as the
> > constraints are correct and the tests pass.
> >
> > Perhaps I'm a little risk adverse but this seems a little strange to me. Can
> > folks that know more about how this came about help me understand why that 
> > is?
> >
> > Yours Tony.
> >
> > [1] 
> > https://github.com/openstack/requirements/blob/master/README.rst#for-upgrading-requirements-versions
> >   
>  
> With constraints, the requirements minimum bump is pretty low risk. Very
> little of our jobs are impacted by it.
>  
> It's in many ways more risking to leave minimums where they are and bump
> constraints, because the minimums could be lying that they still work at
> the lower level.
>  
> -Sean

I maintain a few libraries outside of OpenStack that have generous lower limits 
and testing them is resource intensive both as a developer and in continuous 
integration. I'd love to see OpenStack be *more* aggressive about the oldest 
version it supports because in most cases I severely distrust the version 
ranges we use. I do recognize, however, that we have to coordinate with some 
distributions that will not update their packaged versions (which are often an 
old version number with security patches poorly cherry-picked). So you may need 
to coordinate with them before bumping version minimums as well.

--  
Ian Cordasco


__
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

Re: [openstack-dev] [requirements] History lesson please

[Sean Dague]

On 08/09/2016 02:38 AM, Tony Breeds wrote:
> Hi all,
> I guess this is aimed at the long term requirements team members.
> 
> The current policy for approving requirements[1] bumps contains the following 
> text:
> 
> Changes to update the minimum version of a library developed by the
> OpenStack community can be approved by one reviewer, as long as the
> constraints are correct and the tests pass.
> 
> Perhaps I'm a little risk adverse but this seems a little strange to me.  Can
> folks that know more about how this came about help me understand why that is?
> 
> Yours Tony.
> 
> [1] 
> https://github.com/openstack/requirements/blob/master/README.rst#for-upgrading-requirements-versions

With constraints, the requirements minimum bump is pretty low risk. Very
little of our jobs are impacted by it.

It's in many ways more risking to leave minimums where they are and bump
constraints, because the minimums could be lying that they still work at
the lower level.

-Sean

-- 
Sean Dague
http://dague.net

__
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

[openstack-dev] [requirements] History lesson please

[Tony Breeds]

Hi all,
I guess this is aimed at the long term requirements team members.

The current policy for approving requirements[1] bumps contains the following 
text:

Changes to update the minimum version of a library developed by the
OpenStack community can be approved by one reviewer, as long as the
constraints are correct and the tests pass.

Perhaps I'm a little risk adverse but this seems a little strange to me.  Can
folks that know more about how this came about help me understand why that is?

Yours Tony.

[1] 
https://github.com/openstack/requirements/blob/master/README.rst#for-upgrading-requirements-versions


signature.asc
Description: PGP signature
__
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