This also raises the question of how to handle tiers like
REDUCED_REDUNDANCY for S3:
public enum StorageClass {
STANDARD(Tier.STANDARD),
STANDARD_IA(Tier.INFREQUENT),
REDUCED_REDUNDANCY(Tier.STANDARD), // TODO: correct mapping?
GLACIER(Tier.ARCHIVE);
}
On Wed, Oct 11, 2017 at 01:17:53AM -0700, Andrew Gaul wrote:
> I am working on per-blob storage tiers which allows users to cost- or
> access-optimize their blob data:
>
> https://github.com/jclouds/jclouds/pull/1148
>
> Three providers, Azure, GCS, and S3, support similar tiers which I have
> named STANDARD, INFREQUENT, and ARCHIVE. Some other providers, Atmos,
> B2, and Swift, do not support tiering. How should these providers
> handle requests with non-STANDARD tiers? We could throw an
> UnsupportedOperationException or we could map unsupported tiers into the
> STANDARD tier. BlobStore does not have a precedent for this so I wonder
> what compute does when users request machines with too much memory or
> storage?
>
> --
> Andrew Gaul
> http://gaul.org/
--
Andrew Gaul
http://gaul.org/
