On Tue, Nov 10, 2009 at 08:36:13AM -, 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
On Tue, Nov 10, 2009 at 08:36:13AM -, 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
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.
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
On Wed, Sep 23, 2009 at 10:12:28AM -, 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 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
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
