PBR

free-format signed tags treated as versions

Bug #1356784 reported by Bence Romsics
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
PBR
Fix Released
Critical
Robert Collins
PBR next-kilo

Bug Description

pbr (incorrectly) accepts free-form tags as versions and puts those in the pip metadata. until recently this was not very visible, but since pbr started validating the versions it created, bad tags result in bad versions.

The symptom will look something like:
Traceback (most recent call last):
  File "/usr/local/bin/nova-api", line 10, in <module>
    sys.exit(main())
  File "/opt/stack/nova/nova/cmd/api.py", line 40, in main
    config.parse_args(sys.argv)
  File "/opt/stack/nova/nova/config.py", line 36, in parse_args
    version=version.version_string(),
  File "/usr/local/lib/python2.7/dist-packages/pbr/version.py", line 433, in version_string
    return self.semantic_version().brief_string()
  File "/usr/local/lib/python2.7/dist-packages/pbr/version.py", line 428, in semantic_version
    self._semantic = self._get_version_from_pkg_resources()
  File "/usr/local/lib/python2.7/dist-packages/pbr/version.py", line 416, in _get_version_from_pkg_resources
    return SemanticVersion.from_pip_string(result_string)
  File "/usr/local/lib/python2.7/dist-packages/pbr/version.py", line 155, in from_pip_string
    major = int(components[0])
ValueError: invalid literal for int() with base 10: 'cee-trunkport'
n-api failed to start

(In this case the nova repository has a most recent signed tag 'cee/trunkport-rc2')

WORKAROUNDS
===========

In the source tree with the tag either:
 - convert the signed tag to an unsigned tag
 - add a newer tag that is a valid version
 - delete the signed tag

Then sdist and install the resulting package

PROPOSED FIX
============

Ignore such tags and walk history back to an actual usable tag

See original description
Revision history for this message
Jeremy Stanley (fungi) wrote :

I believe https://review.openstack.org/114093 fixes this... can you confirm?

Changed in pbr:
status: New → In Progress
status: In Progress → Incomplete
Revision history for this message
Robert Collins (lifeless) wrote :

This is a bug, not an intentional aspect of semver. It won't be fixed be 114093 but the higher up patches should fix it if we can get them through. I'll add a specific test to ensure that this is fixed.

The issue we have here is that the describe command is returning the most recent tag and thats not actually a release. So we need to walk history ourselves back to a release (which is part of the newer code).

Changed in pbr:
status: Incomplete → Confirmed
Revision history for this message
Robert Collins (lifeless) wrote :

I've looked deeper and we'll actually need a specific patch to handle this. We were previously creating sdists like:

$PROJECT-bar.1.g49655c6

(for a tag of 'bar' one commit back).

Which is obviously *totally* wrong - as the project name and version get mixed in.

summary: - Introduction of semantic versioning support breaks devstack if
- repository contains free-format tags
+ free-format signed tags treated as versions
Robert Collins (lifeless)
description: updated
Revision history for this message
Robert Collins (lifeless) wrote :

marked critical because of the impact on users in this situation

Changed in pbr:
status: Confirmed → Triaged
importance: Undecided → Critical
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to pbr (master)

Fix proposed to branch: master
Review: https://review.openstack.org/114403

Changed in pbr:
assignee: nobody → Robert Collins (lifeless)
status: Triaged → In Progress
Revision history for this message
Bence Romsics (rubasov+launchpad) wrote :

Thanks for the quick reaction.

I have given the proposed patch some testing and it works for me.

I have a note on the title: I had unsigned annotated tags in my repository, so I believe it doesn't really matter if the tag is signed or not.

For the record this is what I tested:

I have set RECLONE=no in my devstack, then I did:

cd /opt/stack/pbr
git fetch https://review.openstack.org/openstack-dev/pbr refs/changes/03/114403/1 && git checkout FETCH_HEAD
git checkout -b review/114403/1
cd $back_to_devstack
./stack.sh

Now I have pbr version as expected:

$ pip freeze | grep -w pbr
pbr==0.11.0.dev12.g0708206

Nova got installed (in develop mode) with a better version:

$ grep ^Version: /opt/stack/nova/nova.egg-info/PKG-INFO
Version: 2013.2.3.dev1.ga73da36

Yes, it's really old, but that's probably correct. The point is this is now not based on the free-format tags present in my nova repo.

nova-api and devstack started up as expected.

Doug Hellmann (doug-hellmann)
Changed in pbr:
milestone: none → next-juno
Doug Hellmann (doug-hellmann)
Changed in pbr:
milestone: next-juno → juno-rc1
Thierry Carrez (ttx)
Changed in pbr:
milestone: juno-rc1 → next-juno
Doug Hellmann (doug-hellmann)
Changed in pbr:
milestone: next-juno → juno-rc1
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to pbr (master)

Reviewed: https://review.openstack.org/114403
Committed: https://git.openstack.org/cgit/openstack-dev/pbr/commit/?id=dc62764a240f9d94d2def02ab13bdf18560d07d5
Submitter: Jenkins
Branch: master

commit dc62764a240f9d94d2def02ab13bdf18560d07d5
Author: Robert Collins <email address hidden>
Date: Fri Aug 15 12:41:41 2014 +1200

    Only consider tags that look like versions.

    pbr has been allowing any tag (e.g. 'fred') to be a version - but fred
    is clearly not a version! Since git describe cannot validate versions
    for us today, we need to perform the describe calculations ourselves.

    In order for this to work on Python3, a missing method __hash__ needed
    to be added to SemanticVersion.

    Change-Id: I09fa54231e77ae7671aa6f84eb91fd655e49ab25
    Closes-Bug: #1356784

Changed in pbr:
status: In Progress → Fix Committed
Doug Hellmann (doug-hellmann)
Changed in pbr:
milestone: next-juno → next-kilo
Robert Collins (lifeless)
Changed in pbr:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.