You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Gaul <ga...@apache.org> on 2017/10/11 08:17:53 UTC
storage tiers and user intent
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/
Re: storage tiers and user intent
Posted by Ignasi Barrera <na...@apache.org>.
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 <ga...@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/
Re: storage tiers and user intent
Posted by Andrew Gaul <ga...@apache.org>.
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/