This matches how most blobstores operate: delete container is a single
operation, not a compound operation which recursively deletes blobs.
Azure is the only provider which allows deleting a non-empty
container.
This commit replaces file resource-based test inputs with in-memory
equivalents. This is more consistent and efficient than the previous
approach. Also resized some test inputs to be partSize + 1 instead of
2 * partSize. Tested against aws-s3, blobstore, core, cloudfiles-us,
and filesystem.
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.
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.
