settingsLogin | Registersettings

[openstack-dev] [all] PBR 2.0.0 release *may* cause gate failures

0 votes

Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

It seems that several projects outside both inside and outside OpenStack have
capped pbr <2.0.0 so we can't actually use this release yet. The requirements
team will work with all projects to remove the cap of pbr in those projects.

The good news is that projects using upper-constraints.txt are insulated from
this and shouldn't be affected[1]. However upper-constraints.txt isn't being used
by all projects and those projects will start seeing

ContextualVersionConflicts: (pbr 2.0.0 in gate logs. It's recommended that
those projects add a local ban for pbr and associate it with:
https://bugs.launchpad.net/openstack-requirements/+bug/1668848

Then once the situation is resolved we can unwind and remove the temporary caps.

Yours Tony.

[1] There is at least 1 corner case where the coverage job installed directly
from a git URL and therefore that wasn't protected.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

asked Mar 1, 2017 in openstack-dev by Tony_Breeds (19,660 points)   3 6 11

18 Responses

0 votes

On 03/01/2017 12:26 AM, Tony Breeds wrote:
Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

It seems that several projects outside both inside and outside OpenStack have
capped pbr <2.0.0 so we can't actually use this release yet. The requirements
team will work with all projects to remove the cap of pbr in those projects.

The good news is that projects using upper-constraints.txt are insulated from
this and shouldn't be affected[1]. However upper-constraints.txt isn't being used
by all projects and those projects will start seeing

ContextualVersionConflicts: (pbr 2.0.0 in gate logs. It's recommended that
those projects add a local ban for pbr and associate it with:
https://bugs.launchpad.net/openstack-requirements/+bug/1668848

Then once the situation is resolved we can unwind and remove the temporary caps.

Yours Tony.

[1] There is at least 1 corner case where the coverage job installed directly
from a git URL and therefore that wasn't protected.

So, I feel like we hit a similar issue around Vancouver with a pbr bump.
Can we stop capping pbr per rule now?

I also wonder if we can grant the release team +2 permissions on
everything in OpenStack so that fixes like this can be gotten in quickly
without having to go chase a bunch of teams.

-Sean

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by Sean_Dague (66,200 points)   4 8 14
0 votes

On 01/03/2017 13:00, Sean Dague wrote:
On 03/01/2017 12:26 AM, Tony Breeds wrote:

Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

It seems that several projects outside both inside and outside OpenStack have
capped pbr <2.0.0 so we can't actually use this release yet. The requirements
team will work with all projects to remove the cap of pbr in those projects.

The good news is that projects using upper-constraints.txt are insulated from
this and shouldn't be affected[1]. However upper-constraints.txt isn't being used
by all projects and those projects will start seeing

ContextualVersionConflicts: (pbr 2.0.0 in gate logs. It's recommended that
those projects add a local ban for pbr and associate it with:
https://bugs.launchpad.net/openstack-requirements/+bug/1668848

Then once the situation is resolved we can unwind and remove the temporary caps.

Yours Tony.

[1] There is at least 1 corner case where the coverage job installed directly
from a git URL and therefore that wasn't protected.

So, I feel like we hit a similar issue around Vancouver with a pbr bump.
Can we stop capping pbr per rule now?

I also wonder if we can grant the release team +2 permissions on
everything in OpenStack so that fixes like this can be gotten in quickly
without having to go chase a bunch of teams.

That sounds like a good idea to me.

-Sean


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by graham.hayes_at_hpe. (6,780 points)   1 2 2
0 votes

Excerpts from Sean Dague's message of 2017-03-01 07:57:31 -0500:

On 03/01/2017 12:26 AM, Tony Breeds wrote:

Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

It seems that several projects outside both inside and outside OpenStack have
capped pbr <2.0.0 so we can't actually use this release yet. The requirements
team will work with all projects to remove the cap of pbr in those projects.

The good news is that projects using upper-constraints.txt are insulated from
this and shouldn't be affected[1]. However upper-constraints.txt isn't being used
by all projects and those projects will start seeing

ContextualVersionConflicts: (pbr 2.0.0 in gate logs. It's recommended that
those projects add a local ban for pbr and associate it with:
https://bugs.launchpad.net/openstack-requirements/+bug/1668848

Then once the situation is resolved we can unwind and remove the temporary caps.

Yours Tony.

[1] There is at least 1 corner case where the coverage job installed directly
from a git URL and therefore that wasn't protected.

So, I feel like we hit a similar issue around Vancouver with a pbr bump.
Can we stop capping pbr per rule now?

Tony identified caps in 5 OpenStack community projects (see [1]) as well
as powervm and python-jsonpath-rw-ext. Pull requests to those other
projects are linked from the bug [2].

The sqlalchemy-migrate 0.11.0 release should fix that library. The
release team will prioritize releases for the other dependencies today
as they come in.

Doug

[1] https://review.openstack.org/#/q/topic:bug/1668848
[2] https://bugs.launchpad.net/openstack-requirements/+bug/1668848


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by Doug_Hellmann (87,520 points)   3 4 11
0 votes

On 2017-03-01 06:26, Tony Breeds wrote:
Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

Can we change the sphinx==1.3.6 line in upper-constraints now?

Andreas

It seems that several projects outside both inside and outside OpenStack have
capped pbr <2.0.0 so we can't actually use this release yet. The requirements
team will work with all projects to remove the cap of pbr in those projects.

The good news is that projects using upper-constraints.txt are insulated from
this and shouldn't be affected[1]. However upper-constraints.txt isn't being used
by all projects and those projects will start seeing

ContextualVersionConflicts: (pbr 2.0.0 in gate logs. It's recommended that
those projects add a local ban for pbr and associate it with:
https://bugs.launchpad.net/openstack-requirements/+bug/1668848

Then once the situation is resolved we can unwind and remove the temporary caps.

Yours Tony.

[1] There is at least 1 corner case where the coverage job installed directly
from a git URL and therefore that wasn't protected.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by Andreas_Jaeger (17,140 points)   2 3 4
0 votes

Excerpts from Andreas Jaeger's message of 2017-03-01 16:22:24 +0100:

On 2017-03-01 06:26, Tony Breeds wrote:

Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

Can we change the sphinx==1.3.6 line in upper-constraints now?

We're currently running into failures updating requirements because of
the pbr cap in several libraries.

I see requestsexceptions, sqlalchemy-migrate, yaql, fairy-slipper,
pypowervm, gnocchiclient, reno, and aodhclient mentioned in
http://logs.openstack.org/88/439588/2/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/97625f3/console.html
for example.

I'm working on reno right now.

Doug

Andreas

It seems that several projects outside both inside and outside OpenStack have
capped pbr <2.0.0 so we can't actually use this release yet. The requirements
team will work with all projects to remove the cap of pbr in those projects.

The good news is that projects using upper-constraints.txt are insulated from
this and shouldn't be affected[1]. However upper-constraints.txt isn't being used
by all projects and those projects will start seeing

ContextualVersionConflicts: (pbr 2.0.0 in gate logs. It's recommended that
those projects add a local ban for pbr and associate it with:
https://bugs.launchpad.net/openstack-requirements/+bug/1668848

Then once the situation is resolved we can unwind and remove the temporary caps.

Yours Tony.

[1] There is at least 1 corner case where the coverage job installed directly
from a git URL and therefore that wasn't protected.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by Doug_Hellmann (87,520 points)   3 4 11
0 votes

On 2017-03-01 17:13, Doug Hellmann wrote:
Excerpts from Andreas Jaeger's message of 2017-03-01 16:22:24 +0100:

On 2017-03-01 06:26, Tony Breeds wrote:

Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

Can we change the sphinx==1.3.6 line in upper-constraints now?

We're currently running into failures updating requirements because of
the pbr cap in several libraries.

I see requestsexceptions, sqlalchemy-migrate, yaql, fairy-slipper,
pypowervm, gnocchiclient, reno, and aodhclient mentioned in
http://logs.openstack.org/88/439588/2/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/97625f3/console.html
for example.

I'm working on reno right now.

thanks

fairy-slipper is retired, let's remove it -
https://review.openstack.org/439769

Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by Andreas_Jaeger (17,140 points)   2 3 4
0 votes

Excerpts from Andreas Jaeger's message of 2017-03-01 19:50:51 +0100:

On 2017-03-01 17:13, Doug Hellmann wrote:

Excerpts from Andreas Jaeger's message of 2017-03-01 16:22:24 +0100:

On 2017-03-01 06:26, Tony Breeds wrote:

Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

Can we change the sphinx==1.3.6 line in upper-constraints now?

We're currently running into failures updating requirements because of
the pbr cap in several libraries.

I see requestsexceptions, sqlalchemy-migrate, yaql, fairy-slipper,
pypowervm, gnocchiclient, reno, and aodhclient mentioned in
http://logs.openstack.org/88/439588/2/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/97625f3/console.html
for example.

I'm working on reno right now.

thanks

fairy-slipper is retired, let's remove it -
https://review.openstack.org/439769

Andreas

Based on the nature of the failures, I think we're going to have to get
releases of all of the other projects up, and then prepare one patch in
the requirements repo to update constraints all at one time.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by Doug_Hellmann (87,520 points)   3 4 11
0 votes

Excerpts from Doug Hellmann's message of 2017-03-01 14:04:19 -0500:

Excerpts from Andreas Jaeger's message of 2017-03-01 19:50:51 +0100:

On 2017-03-01 17:13, Doug Hellmann wrote:

Excerpts from Andreas Jaeger's message of 2017-03-01 16:22:24 +0100:

On 2017-03-01 06:26, Tony Breeds wrote:

Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

Can we change the sphinx==1.3.6 line in upper-constraints now?

We're currently running into failures updating requirements because of
the pbr cap in several libraries.

I see requestsexceptions, sqlalchemy-migrate, yaql, fairy-slipper,
pypowervm, gnocchiclient, reno, and aodhclient mentioned in
http://logs.openstack.org/88/439588/2/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/97625f3/console.html
for example.

I'm working on reno right now.

thanks

fairy-slipper is retired, let's remove it -
https://review.openstack.org/439769

Andreas

Based on the nature of the failures, I think we're going to have to get
releases of all of the other projects up, and then prepare one patch in
the requirements repo to update constraints all at one time.

Doug

Most of the projects involved are trying to take action, but I haven't
seen any updates on the pypowervm pull request in
https://github.com/powervm/pypowervm/pull/1

Can someone contact that team and ask them to merge it and push a new
release?

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by Doug_Hellmann (87,520 points)   3 4 11
0 votes

On Wed, Mar 1, 2017 at 2:12 PM, Doug Hellmann doug@doughellmann.com wrote:
Excerpts from Doug Hellmann's message of 2017-03-01 14:04:19 -0500:

Excerpts from Andreas Jaeger's message of 2017-03-01 19:50:51 +0100:

On 2017-03-01 17:13, Doug Hellmann wrote:

Excerpts from Andreas Jaeger's message of 2017-03-01 16:22:24 +0100:

On 2017-03-01 06:26, Tony Breeds wrote:

Hi All,
Earlier today the release team tagged PBR 2.0.0. The reason for the major
version bump is because warnerrors has been removed in favor of
warning-is-error from sphinx >= 1.5.0.

Can we change the sphinx==1.3.6 line in upper-constraints now?

We're currently running into failures updating requirements because of
the pbr cap in several libraries.

I see requestsexceptions, sqlalchemy-migrate, yaql, fairy-slipper,
pypowervm, gnocchiclient, reno, and aodhclient mentioned in
http://logs.openstack.org/88/439588/2/check/gate-requirements-tox-py27-check-uc-ubuntu-xenial/97625f3/console.html
for example.

I'm working on reno right now.

thanks

fairy-slipper is retired, let's remove it -
https://review.openstack.org/439769

Andreas

Based on the nature of the failures, I think we're going to have to get
releases of all of the other projects up, and then prepare one patch in
the requirements repo to update constraints all at one time.

Doug

Most of the projects involved are trying to take action, but I haven't
seen any updates on the pypowervm pull request in
https://github.com/powervm/pypowervm/pull/1

Can someone contact that team and ask them to merge it and push a new
release?

Done. over on #openstack-nova

[11:40:49] thorst : Anyone around to merge this PR and cut a
release for pypowervm? https://github.com/powervm/pypowervm/pull/1
[11:41:20] dims: Yeah, we're working on getting a new rev of
that. It'd be pypowervm 1.0.0.4.1 to take in the new req. adreznec
is working on it.
[11:41:32] great thanks thorst and adreznec
[11:41:42] dims: thorst Yep, just working on that now
[11:41:44] thx for letting us know!

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 1, 2017 by Davanum_Srinivas (35,920 points)   2 4 9
0 votes

On Mar 1, 2017, at 4:57 AM, Sean Dague sean@dague.net wrote:

I also wonder if we can grant the release team +2 permissions on
everything in OpenStack so that fixes like this can be gotten in quickly
without having to go chase a bunch of teams.

I would be very much opposed to this. Isn't this why we have cross-project liaisons, defaulting back to the PTLs? Ultimately, project teams need to own the change and its repercussions. As we've seen with things like eventlet, requirements changes have ripple effects, and the project teams are best-suited to foresee those consequences within their own domain.

Tim__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Mar 1, 2017 by Tim_Burke (380 points)  
...