deprecated hardware types in EC2 are flagged using this, according to latest AWS advice,
to fix situations where deprecated hardware types would be chosen when a non-deprecated alternative exists.
we also deprecate T2 because it requires a VPC.
also fixes semantics of ImagesToRegionAndIdMap to match the logic used in the TemplateBuilderImpl;
RegionAndName should contain the ID not the ProviderID. this is only really used in tests so no external impact.
(previously the cache only worked if provider ID matched the non-location segment of the image ID.)
however this does now assert that image id's are in the right format for AWS, as suggested by @nacx.
The names created do not match those searched for.
They are created in FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java
and have are of this form jclouds#I-0#e96.
But for example jclouds#I-0#us-east-1#* is used as the search term.
- Some users get a DependencyVioloation, rather than InvalidGroup.InUse,
when attempting to delete the security group. This caused
cleanupIncidentalResources to propagate an exception.
- Fixes it by converting this to an IllegalStateException (in same
way as is done for “InUse”)
- Adds tests (using MockWebServer) for happy-path and for failing
to delete the security group with each of InUse and DependencyViolation
responses.
- Adds Timeouts.cleanupIncidentalResources
- Use that timeout in EC2, when retrying the deletion of security group
on VM deletion (previously hard-coded as 3 seconds).
- Configure that timeout in the tests, so deterministic number of retries
This avoids unneeded garbage, especially during XML parsing. Replaced
with:
find -name \*.java | xargs sed -i 's/^\( *[^ ]*\) = new StringBuilder();$/\1.setLength(0);/'
While they're implemented in apis/ec2, the tests are in
providers/aws-ec2, generally, to make sure ec2-alike clones won't barf
on them. We're exercising creation of volumes, images and instances
with the new options. I also had to do some sketchy wait-and-loop'ing
in AMIAPILiveTest.testCreateAndListEBSBackedImage() due to what seems
to be a delay on new AMIs showing up in filtered DescribeImages calls,
though they'll show up instantly when you specify the image ID. Go figure.
Images were cached in memory using a memoized supplier. To allow growing
this cache with the discovered images, the ImageCacheSupplier class has
been created. It provides an in-memory cache with all discovered images
and acts as a view over the image cache that also provides access to
them.
The in-memory cache for the discovered images expires with the session,
just as the image cache does.
The default memoized image supplier has been changed to the
ImageCacheSupplier, to make sure all providers get injected the right
instance, and the old supplier has been qualified with the 'imageCache'
name, in case a provider needs the basic image cache.
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.
Ignasi Barrera
Alex Heneveld
Andrew Bayer
Stuart Hendren
Aled Sage
Jeremy Daggett
Adrian Cole
Reynald Borer
Adrian Cole
Andrew Gaul
Andrew Phillips