euca-describe-snapshots invalid literal for int() with base 10

Bug #520707 reported by Scott Moser on 2010-02-11
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
boto
Unknown
Unknown
eucalyptus (Ubuntu)
Medium
Unassigned
Lucid
High
Unassigned
python-boto (Ubuntu)
High
Unassigned
Lucid
High
Unassigned

Bug Description

Binary package hint: euca2ools

Per Dan, euca-describe-snapshots doesn't work on lucid due to boto 1.9.

> euca-describe-snapshots
> -----------
> root@gibson:/home/nurmi/euca/thunder-ccnc-main# euca-describe-snapshots
> invalid literal for int() with base 10: 'n/a'

Scott Moser (smoser) wrote :

for what its worth, this works fine when pointed at ec2, it seems to work fine with:
export EC2_SECRET_KEY="my-secret-key" EC2_ACCESS_KEY="my-access-key" EC2_URL=https://ec2.amazonaws.com
euca-describe-snapshots

so i can't at the moment recreate. maybe its an error when there are no snapshots ?

Mathias Gug (mathiaz) wrote :

I can confirm the bug when running in UEC (with eucalyptus 1.6.2~bzr1189-0ubuntu1):

ubuntu@cempedak:~$ euca-create-volume --size 1 --zone UEC-TEST1 test1
VOLUME vol-5F220658 1 creating 2010-02-12T21:42:52.872Z

ubuntu@cempedak:~$ euca-describe-snapshots

ubuntu@cempedak:~$ euca-create-snapshot vol-5F220658
SNAPSHOT snap-5945061F vol-5F220658 pending 2010-02-12T21:43:52.297Z
        0%

ubuntu@cempedak:~$ euca-describe-snapshots
invalid literal for int() with base 10: 'n/a'

Scott Moser (smoser) wrote :

Just verified the following with environment set to point to ec2 us-east-1:
$ euca-create-volume --zone us-east-1a --size 1 sm1234
VOLUME vol-eb7bb782 1 creating 2010-02-12T21:41:50.000Z
$ euca-create-snapshot vol-eb7bb782
SNAPSHOT snap-456f332c vol-eb7bb782 pending 2010-02-12T21:42:22.000Z
$ euca-describe-snapshots snap-456f332c
SNAPSHOT snap-456f332c vol-eb7bb782 completed 2010-02-12T21:42:22.000Z 100%
$ euca-delete-snapshot snap-456f332c
SNAPSHOT snap-456f332c
$ euca-delete-volume vol-eb7bb782
VOLUME vol-eb7bb782

Also did a ' euca-describe-snapshots' without a snapshot argument, and it worked fine.

Mathias Gug (mathiaz) on 2010-02-12
Changed in euca2ools (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Scott Moser (smoser) wrote :

mathiaz is able to reproduce this against uec, so that suggests that its something coming back from eucalyptus that isn't comaptible with boto that works with ec2.

I suspect we're failing in boto/ec2/snapshot.py:endElement
boto 1.9 added:
        elif name == 'ownerId':
            self.owner_id = value
        elif name == 'volumeSize':
            self.volume_size = int(value)
        elif name == 'description':
            self.description = value

Scott Moser (smoser) wrote :

This isn't easily fixable in euca2ools. I'm moving this from euca2ools to boto, and subsequently will open a task against Eucalyptus.

The real problem is in Eucalyptus putting 'n/a' as the value for volumeSize in returned data.

We can either patch boto to work around the Eucalyptus bug, or fix the Eucalyptus bug. The patch I attached works around in boto.

affects: euca2ools (Ubuntu) → python-boto (Ubuntu)
Changed in python-boto (Ubuntu):
status: Confirmed → Triaged
Changed in eucalyptus (Ubuntu):
importance: Undecided → High
Changed in python-boto (Ubuntu):
importance: Medium → High
Scott Moser (smoser) wrote :

It appears to me that this is a regression caused by the ubuntu change at:

http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/eucalyptus/lucid/revision/113?start_revid=113

This is not in Eucalyptus trunk. Just from reading I expect that the trunk will not show this bug as it does not provide a 'volumeSize' at all.

tags: added: patch
Thierry Carrez (ttx) wrote :

@Scott: not sure I follow you. rev 113 (together with rev 112) in that branch look like the result of a merge from upstream's bzr1166 to bzr1176, nothing specific to ubuntu. So the same code should be in eucalyptus 1.6.2 branch (lp:~eucalyptus-maintainers/eucalyptus/1.6.2), which is also trunk (lp:eucalyptus).

Scott Moser (smoser) wrote :

A similar fix to mine was accepted upstream boto, see comment at [1] and change at [2]. I suggest we just cherry-pick the boto change.

[1] http://code.google.com/p/boto/issues/detail?id=336
[2] http://code.google.com/p/boto/source/detail?r=1489

Scott Moser (smoser) wrote :

lp:~smoser/ubuntu/lucid/python-boto/lucid has the above revision cherry picked. Please review and apply to python-boto for lucid.

Scott Moser (smoser) on 2010-02-17
Changed in python-boto (Ubuntu):
milestone: none → lucid-alpha-3
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-boto - 1.9b-1ubuntu3

---------------
python-boto (1.9b-1ubuntu3) lucid; urgency=low

  * work around non-int data in volumeSize (LP: #520707)
 -- Scott Moser <email address hidden> Wed, 17 Feb 2010 11:51:05 -0500

Changed in python-boto (Ubuntu Lucid):
status: Triaged → Fix Released
Thierry Carrez (ttx) wrote :

Unnominating eucalyptus task for lucid (doesn't mean it shouldn't be fixed)

Changed in eucalyptus (Ubuntu Lucid):
status: New → Won't Fix
Thierry Carrez (ttx) on 2010-03-04
Changed in eucalyptus (Ubuntu):
importance: High → Medium
status: New → Confirmed
Emmet Hikory (persia) on 2010-03-19
tags: added: patch-submitted-upstream
Emmet Hikory (persia) on 2010-03-19
tags: added: patch-forwarded-upstream
removed: patch-submitted-upstream
Changed in eucalyptus (Ubuntu):
status: Confirmed → Fix Released
Neil Soman (neilsoman) wrote :

I object to fixing this in the client library. If this is a bug in the service, it should be fixed in the service. So what happens when it is fixed in Eucalyptus? It is removed from boto? You could argue that it doesn't have to be, since boto would continue to work regardless of whether an int or a string is returned by the service, but it is best to fix problems where they arise and not introduce needless client workarounds. Potentially, this approach leads to a number of hacks on the client end that are unnecessary, will work with only a single client and potentially reduces code quality.

Dave Walker (davewalker) wrote :

Subscribing Neil Soman for comment.

@Neil, Do you know if this issue has been fixed in the current development version of Eucalyptus?

Thanks.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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