Documentation for --url flag is ambiguous

[Garrett Holmstrom]

The meaning of the "--url" flag in euca-*'s and the man pages' documentation is ambiguous as to whether or not it refers to a computation (e.g., EC2) or storage (e.g., S3) server. Since this varies by tool, it would be less ambiguous to specify which service each tool intends to connect to instead of simply saying, "-U, --url URL of the Cloud to connect to."

[Robert (robert-redhat-bugs-1)]

Description of problem:
It seems most of the euca tools use the URL as ec2.amazonaws.com. However, if that is used with euca-upload-bundle, an impossibly cryptic and verbose error is given. Proper usage is s3.amazonaws.com. Some online docs don't even mention this, so perhaps it was not always this way: http://wiki.debian.org/euca2ools

Version-Release number of selected component (if applicable):
euca2ools.noarch 0:1.2-1.fc12

How reproducible:
Always

Steps to Reproduce:
1. Provide -U ec2.amazonaws.com to euca-upload-bundle instead of -U s3.amazonaws.com

Actual results:
Traceback (most recent call last):
  File "/usr/bin/euca-upload-bundle", line 226, in <module>
    main()
  File "/usr/bin/euca-upload-bundle", line 209, in main
    bucket_instance = ensure_bucket(conn, bucket, canned_acl)
  File "/usr/bin/euca-upload-bundle", line 87, in ensure_bucket
    bucket_instance = connection.get_bucket(bucket)
  File "/usr/lib/python2.6/site-packages/boto/s3/connection.py", line 275, in get_bucket
    rs = bucket.get_all_keys(headers, maxkeys=0)
  File "/usr/lib/python2.6/site-packages/boto/s3/bucket.py", line 211, in get_all_keys
    xml.sax.parseString(body, h)
  File "/usr/lib/python2.6/xml/sax/__init__.py", line 49, in parseString
    parser.parse(inpsrc)
  File "/usr/lib/python2.6/xml/sax/expatreader.py", line 107, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/lib/python2.6/xml/sax/xmlreader.py", line 123, in parse
    self.feed(buffer)
  File "/usr/lib/python2.6/xml/sax/expatreader.py", line 211, in feed
    self._err_handler.fatalError(exc)
  File "/usr/lib/python2.6/xml/sax/handler.py", line 38, in fatalError
    raise exception
xml.sax._exceptions.SAXParseException: http://www.w3.org/TR/html4/strict.dtd:81:4: error in processing external entity reference

Expected results:
A bundle uploaded for use on EC2

Additional info:

[Garrett (garrett-redhat-bugs)]

I'm not sure I understand what the problem here is. If you're going to specify a URI at the command line for a tool made to upload to S3, you should specify a URI for S3, not EC2. You could set the EC2_URL and S3_URL environment variables so the tools can pick the right values up themselves. Based on what I see here I'm not sure this is a bug.

[Robert (robert-redhat-bugs-1)]

I was thinking euca-bundle-image required a -U flag to ec2.amazonaws.com, but it appears to not need this at all...

All I would say then is that the doc should disambiguate for euca-upload-bundle the "cloud" storage from the "cloud" of instances, where one would normally think more of EC2 as the "cloud" than s3.

From euca-upload-bundle -h:
-U, --url URL of the Cloud to connect to.

If there's a better way to output the error instead of dumping the exception trace I would go for that too.

[Garrett (garrett-redhat-bugs)]

Indeed, the description could probably be clearer. In fact, there is a bug for it upstream at https://launchpad.net/bugs/546624, though this sort of change isn't likely to appear in Fedora before the next upstream version.

The root cause of this error is that when you hand euca-upload-bundle the wrong URI boto tries to parse the error message that the EC2 server returns when it gets S3 input, leading to your crash. Please report any bugs related to this behavior against boto. (Fedora's boto package is called "python-boto".)

[Garrett (garrett-redhat-bugs)]

Upstream can decide what to do with this documentation problem; it's minor enough that it isn't worth maintaining a Fedora-specific patch for it. I'll close this for now; if fixing this is important to you feel free to comment on the upstream bug or re-open this one and ask me to ping them about it.

[Andy Grimm (agrimm)]

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/TOOLS-98

Please watch that issue for further updates.