* Wrap getOrderTemplate in VirtualGuestToNodeMetadata.getImage with try/catch
* Address comments from @nacx and @demobox:
- remove the fields of the custom SoftLayerOrderItemDuplicateException and propagate the HttpResponseException
- use of order = null instead of return null
- extend RuntimeException instead IllegalStateException in SoftLayerOrderItemDuplicateException
Conflicts solved:
providers/softlayer/src/main/java/org/jclouds/softlayer/compute/functions/VirtualGuestToNodeMetadata.java
* Wrap getOrderTemplate in VirtualGuestToNodeMetadata.getImage with try/catch
* Address comments from @nacx and @demobox:
- remove the fields of the custom SoftLayerOrderItemDuplicateException and propagate the HttpResponseException
- use of order = null instead of return null
- extend RuntimeException instead IllegalStateException in SoftLayerOrderItemDuplicateException
Conflicts solved:
providers/softlayer/src/main/java/org/jclouds/softlayer/compute/functions/VirtualGuestToNodeMetadata.java
So there were a few problems, but the core ugly one is that what you
pass in for creating a rule allowing groups' access is not the same
thing you get back from a group with such a rule, which makes mapping
between the arguments and the output insanely painful. So now, well,
we do some insanely painful stuff.
Involves some non-trivial reworking of EC2 security group
translation/binding, but it was necessary.
Still problems with a number of tests:
- org.jclouds.aws.ec2.compute.AWSEC2TemplateBuilderLiveTest#testTemplateBuilderWithLessRegions
- org.jclouds.ec2.compute.EC2TemplateBuilderLiveTest#testTemplateBuilderCanUseImageIdWithoutFetchingAllImages
Those seem to be failing because there's caching going on that they're
not expecting, but I could be wrong.
Also failing:
- org.jclouds.aws.ec2.features.PlacementGroupApiLiveTest in general
- org.jclouds.aws.ec2.features.SpotInstanceApiLiveTest - a couple tests
This removes
org.jclouds.ec2.compute.functions.PasswordCredentialsFromWindowsInstanceLiveTest
due to there not being an easily detectable valid AMI for it to run,
and low interest in actually running it in the first place.
Not all S3-compatible providers support virtual host buckets and thus
we should disable this feature by default. Continue to enable virtual
host buckets for AWS-S3 which supports this although this feature
suffers from DNS settling issues. Ran ran integration tests against
AWS-S3 and Scality using its S3 API.