I spent a bit of time tracking down the remnants of #671 / BZ 651562, in
which Apache throws proxy timeout errors because the backend does not
respond in time as a result of API calls timing out.
Most of these errors were fixed a bit ago in deltacloud-client, but it
seems that the versions yum and gem know about don't have this fix, so
the issue was seemingly not fixed. I spent a bit getting deltacloud
0.3.0 running, and was unable to reproduce any errors with Apache
timeouts after attempting to simulate unreachable providers and other
cases where a timeout may occur. The timeouts in deltacloud-client are
slightly shorter than Apache's timeout value.
I'm attaching a patch that cleans up error handling in Conductor
slightly. There were a few spots (e.g., adding a new ProviderAccount
when the provider was unreachable) where the timeout exception was
reaching the user unhandled. This exception now triggers as a
flash[:error] message when raised, in lieu of a hard error.
You will need the 0.3.0 version of deltacloud to test this. (Some older
versions may work, but best not to chance it.) You can build this from
their source, although I suspect some of you already the 0.3.0 RC
[I apologize for the duplicate. I forgot to add the mailing list to cc.]
Ian poked me about something important. Launching a VM in RHEV-M is consists
of 3 explicit steps:
1. Image (assembly actually - it includes OVF) is uploaded into RHEV-M
"Export Domain", which is an NFS share. This is done with cp(1).
2. RHEV-M is told to "import" this templave with a REST API call.
This allocates a volume in one of datacenter's main backing stores,
copies disk images (with qemu-img), and adds OVF to whatever lists.
3. Launching from "template", with another REST API call. This sets
up COW, virsh define, etc.
When I wrote existing dc-rhev-image in iwhd, I thought that step #2 would
be done by the Conductor. Ian told me that he has no code to do it, and
he would rather prefer that I hand him a template that is already "imported".
In the interests of helping the end-to-end chain working as soon as practical,
I have already starting implementing #2 in iwhd, but I still think it's not
something iwhd ought to do. When I'm done, we should take this code and
copy-paste it into Conductor immediately, and here's why.
First, there is management of additional locations, that iwhd has trouble
hiding: the Export domain versus Storage domain in RHEV-M. I am convinced
that whoever uses RHEV-M will end knowing that export domain exists.
Think for example that iwhd does not know how many "normal" storage
domains there are in RHEV-M, so my code selects the first it finds.
Second, each step can fail independently, and iwhd is an annoying layer
of opaque code. I am trying to make sure my error messages explain what
ran out of space as plainly as possible, but it may be ugly.
So, please give this a thought.
I perspective, IMHO, we should use our Red Hat connections and ask RHEV-M
developers to provide a way to upload VMs in the same way Amazon EC2 and
VMware vCloud do it, over HTTP, and directly into the main storage domain
instead of this "Export" domain. We would not be having this discussion
if they allowed direct uploads. Someone better file an RFE.
forwarding this announcement here :-)
Begin forwarded message:
> From: David Lutterkort <lutter(a)redhat.com>
> Date: April 29, 2011 1:00:37 AM GMT+02:00
> To: deltacloud-dev(a)incubator.apache.org
> Cc: general(a)incubator.apache.org
> Subject: [ANNOUNCE] Apache Deltacloud 0.3.0 (incubating)
> Reply-To: general(a)incubator.apache.org
> I am pleased to announce the availability of Apache Deltacloud 0.3.0.
> Apache Deltacloud is a RESTful cloud abstraction API. The release
> consists both of the API server and a Ruby client.
> The release can be found at
> http://www.apache.org/dist/incubator/deltacloud/0.3.0/ Gems and RPM's
> for Fedora will become available shortly.
> Overview of the changes for this release:
> * Dynamic driver switching: select driver on a per-request basis; new
> toplevel 'drivers' collection describing drivers supported by server
> * Create images from running instances (EC2, Mock, GoGrid, Rackspace);
> advertised as action 'create_image' in instance details when possible
> * New 'user_files' feature for create_instance to advertise RAX-style
> injection of user data
> * Return status 204 after successful DELETE operation
> * Return status 401 when authentication fails because of invalid
> * Blobs: support user metadata as key/value pairs passed through
> X-Deltacloud-Blobmeta-KEY: VALUE headers
> * Support HEAD requests to retrieve the operations and methods supported
> by a collection
> * Support for OPTIONS request to retrieve optional and required
> parameters for operations
> * Advertise 'create_instance' action for each image
> * Drivers
> + EC2
> - instance_count feature to allow creating multiple instances at once
> - run commands inside an insance via ssh
> - by default, list images owned by 'amazon', when passing in empty
> owner_id, list _all_ images (thousands)
> + Eucalyptus
> - new driver for Eucalyptus (Sang-Min Park)
> + Gogrid
> - run commands inside an insance via ssh
> - allow creating sandbox instances
> + Rackspace
> - report root password after instance creation
> + SBC
> - new driver for IBM SBC cloud (Eric Woods)
> * run: new method to run commands via ssh
> * drivers: list drivers supported by server
> * properly list blobs in a bucket when showing bucket details
> * full support for managing blobs and buckets
> To unsubscribe, e-mail: general-unsubscribe(a)incubator.apache.org
> For additional commands, e-mail: general-help(a)incubator.apache.org
Michal Fojtik, mfojtik(a)redhat.com
Deltacloud API: http://deltacloud.org
aeolus-all.spec.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/aeolus-all.spec.in b/aeolus-all.spec.in
index 2ee6653..aac9657 100644
@@ -16,6 +16,7 @@ Requires: imagefactory
This is the aeolus meta-package. If you want to install aeolus and all of its