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.
- 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.
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.