[openstack-dev] Urgent PBR code reviews
Mark McLoughlin
markmc at redhat.com
Tue Jun 11 10:34:30 UTC 2013
On Tue, 2013-06-11 at 12:05 +0200, Julien Danjou wrote:
> On Tue, Jun 11 2013, Mark McLoughlin wrote:
>
> Hi Mark,
>
> > I don't think the issue here is "people aren't reviewing fast enough",
> > frankly. The patches are getting a pretty decent amount of attention
> > from reviewers.
>
> Hehe, then I'm just making sure the amount of attention doesn't
> decrease. :-)
>
> > - I don't see a bug report for this:
> >
> > https://bugs.launchpad.net/pbr
> > https://bugs.launchpad.net/ceilometer
> >
> > I've just dug about and found e.g.:
> >
> > http://logs.openstack.org/32108/1/check/gate-ceilometer-python27/2657/console.html.gz
> >
> > pkg_resources.VersionConflict: (requests 1.2.3 (/home/jenkins/workspace/gate-ceilometer-python27/.tox/py27/lib/python2.7/site-packages), Requirement.parse('requests>=1.1,<1.2.1'))
> >
> > Is that the issue?
>
> No, this is easy to fix, and while trying to fix it at:
>
> https://review.openstack.org/#/c/32124/
>
> I've ended with this problem first:
>
> http://logs.openstack.org/32124/1/check/gate-ceilometer-python26/2672/console.html.gz
>
> Which I tried to solve by disabling our nova test
Ok, that does look like an issue with the easy_install change in pbr.
I've filed a bug with all the details I know of:
https://bugs.launchpad.net/pbr/+bug/1189848
> , and then got into this problem:
>
> http://logs.openstack.org/32124/4/check/gate-ceilometer-docs/1550/console.html.gz
>
> Which I've no damn idea where it comes from.
Lovely.
However, I think we need to fix pbr so that you don't have to disable
the nova tests.
> > - It's not clear to me what change in pbr caused the problem. Was it
> > the use of easy_install ?
> >
> > https://review.openstack.org/31778
>
> I couldn't tell, Monty might have a better idea. I already spent hours
> trying to guess where these errors came from, and stopped right after
> Monty told me it was pbr and it'll fix it. :)
Ok, let's learn a lesson though - we need to make sure stuff gets
recorded in launchpad or commit messages.
IRC conversations are all very well, but anyone looking at the reviews
(or even looking at the git history in future) miss all that valuable
context.
> [… not answering the other questions of Mark since I don't have the
> answers :-) …]
>
> > I'm going to review the latest updates to the patches, but at a time
> > like this we actually need the minimum possible churn and some clear
> > thinking ... not super fast reviewing of a big stack of changes. What's
> > the quickest and least risky thing we can do to get Ceilometer
> > unblocked?
>
> I'll be happy with any solution going back or forward, FWIW.
At this point, I'd suggest we delete the newer versions from pypi and
roll back to 0.5.11 ... if that's possible.
Ideally, we'd have a way of testing that pbr changes don't regress stuff
before we push the release to pypi. My approach with oslo.config is to
tag pre-release versions and reference them directly on
tarballs.openstack.org, but that's probably challenging to do with pbr.
I've suggested before that we should push pre-release versions of
oslo.config to our pypi mirror before promoting them to pypi.python.org
but we'd also need to ensure that all OpenStack developers use that
mirror when running devstack or unit tests locally.
Cheers,
Mark.
More information about the OpenStack-dev
mailing list