Open Stack

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,

-clayg




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.
>>
>> --John
>>
>>
>>
>>
>> On Jul 18, 2013, at 2:50 AM, Chmouel Boudjnah <chmouel at enovance.com>
>> wrote:
>>
>> > 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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130718/89419c9d/attachment.html>