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

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 ?

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'

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.

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

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.

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.

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

Sorry, I was comparing lp:ubuntu/lucid/eucalyptus to lp:~eucalyptus-maintainers/eucalyptus/1.6

The code that I tried to point to does exist in lp:~eucalyptus-maintainers/eucalyptus/1.6.2 .

Heres a link:
http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/eucalyptus/lucid/annotate/head%3A/clc/modules/msgs/src/main/java/edu/ucsb/eucalyptus/msgs/VmBlockDevice.groovy

  String ownerId;
  String volumeSize = "n/a";
  String description;

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

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

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

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

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.

Subscribing Neil Soman for comment.

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

Thanks.