jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Cobb (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (JCLOUDS-923) NovaComputeServiceAdapter.listImages fails if any zone API fails
Date Tue, 09 Jun 2015 21:49:01 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14579610#comment-14579610
] 

Jonathan Cobb edited comment on JCLOUDS-923 at 6/9/15 9:48 PM:
---------------------------------------------------------------

This is a decent workaround for now, but it means I now have to manage config (which PROPERTY_ZONES
to declare) based on inspecting Exceptions thrown when launching instances and looking for
telltale signs that a region is behaving badly. Then I would have to re-check periodically
to see if it's back to normal and re-add it. It seems really hacky and more like something
that should be abstracted away by the library. A failure to fetch images from one region API
should not be a fatal error that prevents users from launching an instance in any other region
that is behaving normally. At worst, you cannot launch instances in the region whose API is
misbehaving, right?

>> Upon reflection, it's really not that bad. I can just pass in a single region as
a parameter every time. I end up not being able to reuse some objects, but that's a much cleaner
solution. Sorry about the above :)


was (Author: cobbzilla):
This is a decent workaround for now, but it means I now have to manage config (which PROPERTY_ZONES
to declare) based on inspecting Exceptions thrown when launching instances and looking for
telltale signs that a region is behaving badly. Then I would have to re-check periodically
to see if it's back to normal and re-add it. It seems really hacky and more like something
that should be abstracted away by the library. A failure to fetch images from one region API
should not be a fatal error that prevents users from launching an instance in any other region
that is behaving normally. At worst, you cannot launch instances in the region whose API is
misbehaving, right?

> NovaComputeServiceAdapter.listImages fails if any zone API fails
> ----------------------------------------------------------------
>
>                 Key: JCLOUDS-923
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-923
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-labs-openstack
>    Affects Versions: 1.8.0
>         Environment: Ubuntu 14.04 x64, OpenJDK 7, Rackspace cloud
>            Reporter: Jonathan Cobb
>
> I have an integration test that launches an instance, runs a simple echo command on it
to ensure SSH is working, then destroys the instance.
> This test passes for EC2 and DigitalOcean, and until yesterday it also passed for Rackspace.
Today it is failing. I have tracked down the error to NovaComputeServiceAdapter.listImages
> In my test, I call TemplateBuilder.build to create a Template, then use that Template
in a call to ComputeService.createNodesInGroup to create a node based on the template.
> Within TemplateBuider.build, it calls NovaComputeServiceAdapter.listImages and iterates
over each zone to get a list of images for each zone. 
> [Side question-- why does the TemplateBuilder look up all images for all zones, even
though I have already configured it to use a particular zone (in this case, "IAD")?]
> In any case, even though I am trying to launch in IAD, the call to the SYD zone is failing
(today, was working yesterday), and thus no instances can be launched at all, since the resulting
HttpResponseException is uncaught and bubbles all the way up and out of TemplateBuilder.build.
The full stack trace is here: http://cloudstead.io/downloads/jclouds-exception.txt
> I have made a simple patch that catches the HttpResponseException, logs an error, and
continues loading images from other zones. The patch is here: http://cloudstead.io/downloads/NovaComputeServiceAdapter.java.patch



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message