If the TemplateBuilderImpl is given an imageId but the image can not be
found in the image cache, fallback to the GetImageStrategy to perform a
call to the provider to try to get it.
We've seen that in some cases images are not returned in the image list
but they actually exist in the provider. This fix won't make them
available when filtering by other properties such as the operating system,
etc, but at least will make them available if their id is known.
Added the new ElasticHosts regions.
Updated the ElasticStack api to get the list of standard
drives using an API call. All providers except ServerLove
support the new API call, so the old logic in the ElasticStack
api has been moved to that provider. The rest of providers will now
extract all the OperatingSystem information by parsing the name of the
StandardDrive.
A unit test has been added to the ElasticStack api with all the images
that were hardcoded, to make sure all names are still parsed as expected
and all information in the existing providers is kept.
Modified the default template for all ElasticHosts providers to
match newer Ubuntu images and updated the Template*Live tests
accordingly.
Also refactored the WellKnownImage map to a supplier to lazy load it
when needed and avoid unexpected errors when building the Guice injector
if there are authentication errors or similar.
Callers should instead explicitly set contentMD5, usually with the
results from Guava Hashing.md5(). This narrows the API and removes a
strange IOException from callers. Further it removes a dangerous
rebuffering of arbitrarily-large non-repeatable Payloads.
The only users of this seem to be
org.jclouds.atmos.blobstore.strategy.FindMD5InUserMetadata and
org.jclouds.azureblob.blobstore.strategy.FindMD5InBlobProperties which
are themselves unused.
- Adds networks field/methods to TemplateOptions.
- Adds them to children as well for legacy reasons.
- Deprecates CloudStackTemplateOptions#networkIds methods in favor of #networks.
- TODO: Modify compute abstraction layer for provisioning for nova,
EC2, et al to take advantage of this.
* 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.