* 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.
Refactored the domain model to be immutable and addressed some
inconsistences with the Chef Server API model.
Removed all HEAD methods, as they have been removed from newer versions
of Chef. They were used to test the existance of a given resource, and
with newer versions the only way to do that is via a GET operation.
Now all live tests are passing for Community Chef 0.10.8, 11.0.6 and
Enterprise Chef.
