euca2ools should provide ec2-* symlinks/alternatives

Bug #435140 reported by Thierry Carrez
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
euca2ools (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

Binary package hint: euca2ools

In order to simplify documentation, it might be a good idea for euca2ools to provide ec2-* symlinks to present an similar interface as the ec2-* tools (or use alternatives in both providers) ?

Tags: ec2-images
Thierry Carrez (ttx)
Changed in euca2ools (Ubuntu):
importance: Undecided → Wishlist
status: New → Confirmed
tags: added: ec2-images
Revision history for this message
Eric Hammond (esh) wrote :

The ideal solution would include the ability to easily set up either of the following environments and be able to switch between them:

1) euca2ools without ec2-* symlinks. Optionally, Amazon's ec2-*-tools packages could be installed alongside and commands from either set of tools could be run independently on the same system.

2) euca2ools with ec2-* symlinks. I suppose this should require that Amazon's ec2-*-tools not be installed.

Revision history for this message
Eric Hammond (esh) wrote :

I suggest this ability to support the ec2-* names should be a requirement before the ec2-ami-tools on the Canonical EC2 images are replaced with euca2ools (assuming euca2ools is sufficiently compatible and stable for it to become the default).

It's not just Canonical's documentation which would be made simpler by this, but it would also more closely match all of the existing EC2 documentation and tutorials which have been published. Users and existing software infrastructures running images on EC2 already expect the appropriate AMI commands to be available on the images under the ec2-* names.

The closer the new images match user expectations, the easier adoption will be.

Revision history for this message
Matt Zimmerman (mdz) wrote : Re: [Bug 435140] Re: euca2ools should provide ec2-* symlinks/alternatives

On Wed, Sep 23, 2009 at 10:12:28AM -0000, Eric Hammond wrote:
> I suggest this ability to support the ec2-* names should be a
> requirement before the ec2-ami-tools on the Canonical EC2 images are
> replaced with euca2ools (assuming euca2ools is sufficiently compatible
> and stable for it to become the default).

As I've explained in private email, the ec2-ami-tools are not licensed in a
manner which is suitable for default inclusion in an Ubuntu product. As
such, even though compatibility may not be 100%, we will default to
euca2ools and work to resolve issues as they arise.

My (admittedly limited) experience with the euca2ools has been that they are
quite sufficient for the tasks for which I had been using Amazon's tools.

I'd like to get input from the upstream developers of euca2ools as to the
circumstances under which they would be comfortable providing the ec2-*
names.

--
 - mdz

Revision history for this message
Eric Hammond (esh) wrote :

I just tried using euca2ools for the first time to bundle a running Karmic instance. Apart from the bugs that make it not work at all (bug 450044, bug 479823, bug 479836) I also found a number of other incompatibilities which make it look like more changes are needed than just ec2-* symlinks.

For example,

- euca-upload-bundle requires setting S3_URL instead of just defaulting to https://s3.amazonaws.com as ec2-upload-bundle does.

- euca-register requires setting $EC2_ACCESS_KEY and $EC2_SECRET_KEY instead of using $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY_ID as ec2-register does.

- euca-register requires setting $EC2_URL instead of defaulting to https://ec2.amazonaws.com as ec2-register does.

I haven't tried the euca2ools equivalents for the EC2 API tools, but given the above, I'd guess there's a ways to go before tossing in symlinks will make euca2ools be command line compatible.

Feel free to copy the above points to new bug reports if compatibility is the goal.

Revision history for this message
Eric Hammond (esh) wrote :

Perhaps instead of symlinks, the commands could be short wrappers which set the appropriate envariables.

I'm not sure if Amazon's EC2 API/AMI tools default to "https" or "http" for the API URls. It might be "http", but further research would be appropriate for compatibility, especially as this affects security and performance.

Revision history for this message
Matt Zimmerman (mdz) wrote :

On Tue, Nov 10, 2009 at 08:36:13AM -0000, Eric Hammond wrote:
> I just tried using euca2ools for the first time to bundle a running
> Karmic instance. Apart from the bugs that make it not work at all (bug
> 450044, bug 479823, bug 479836) I also found a number of other
> incompatibilities which make it look like more changes are needed than
> just ec2-* symlinks.
>
> For example,
>
> - euca-upload-bundle requires setting S3_URL instead of just defaulting
> to https://s3.amazonaws.com as ec2-upload-bundle does.
>
> - euca-register requires setting $EC2_ACCESS_KEY and $EC2_SECRET_KEY
> instead of using $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY_ID as
> ec2-register does.
>
> - euca-register requires setting $EC2_URL instead of defaulting to
> https://ec2.amazonaws.com as ec2-register does.
>
> I haven't tried the euca2ools equivalents for the EC2 API tools, but
> given the above, I'd guess there's a ways to go before tossing in
> symlinks will make euca2ools be command line compatible.
>
> Feel free to copy the above points to new bug reports if compatibility
> is the goal.

For any issues you find with euca2ools which cause you problems on EC2,
please file bugs using "ubuntu-bug euca2ools" and mention the bug number
here for tracking.

--
 - mdz

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

Other bug subscribers

Remote bug watches

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