[openstack-dev] [Swift] erasure codes, digging deeper
clay.gerrard at gmail.com
Thu Jul 18 17:52:13 UTC 2013
I'm not sure if I agree with the giving justifications (harder to bill,
confusing to users), but I *do* think it could simplify some of the
implementation (since users can't create accounts withe the "wrong" storage
policy willy nilly).
I think eventually some use cases may want mixed accounts (particularly for
COPY), but having two accounts in the interim seems like it might be a good
compromise - especially if there is indeed a reduction in complexity.
Definitely worth considering IMHO.
Good idea Chuck & Chmouel,
On Thu, Jul 18, 2013 at 10:31 AM, Chuck Thier <cthier at gmail.com> wrote:
> I'm with Chmouel though. It seems to me that EC policy should be chosen
> by the provider and not the client. For public storage clouds, I don't
> think you can make the assumption that all users/clients will understand
> the storage/latency tradeoffs and benefits.
> On Thu, Jul 18, 2013 at 8:11 AM, John Dickinson <me at not.mn> wrote:
>> Check out the slides I linked. The plan is to enable an EC policy that is
>> then set on a container. A cluster may have a replication policy and one or
>> more EC policies. Then the user will be able to choose the policy for a
>> particular container.
>> On Jul 18, 2013, at 2:50 AM, Chmouel Boudjnah <chmouel at enovance.com>
>> > On Thu, Jul 18, 2013 at 12:42 AM, John Dickinson <me at not.mn> wrote:
>> >> * Erasure codes (vs replicas) will be set on a per-container basis
>> > I was wondering if there was any reasons why it couldn't be as
>> > per-account basis as this would allow an operator to have different
>> > type of an account and different pricing (i.e: tiered storage).
>> > Chmouel.
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev