I'd say we should better map unsupported tiers to the standard one, as
it is more portable. In the end, if the provider does not support
them, users will probably not care that much about them, and mapping
to STANDARD makes sense to me.
On 12 October 2017 at 09:28, Andrew Gaul <g...@apache.org> wrote:
> 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/
