Open Stack

Yes, and I'd imagine that the normal default would be for replicated data.

Moving the granularity from a container to account-based, as Chmouel and Chuck said, is interesting too.

--John

On Jul 18, 2013, at 11:32 AM, Christian Schwede <info at cschwede.de> wrote:

> A solution to this might be to set the default policy as a configuration
> setting in the proxy. If you want a replicated swift cluster just allow
> this policy in the proxy and set it to default. The same for EC cluster,
> just set the allowed policy to EC. If you want both (and let your users
> decide which policy to use) simply configure a list of allowed policies
> with the first one in the list as the default policy in case they don't
> set a policy during container creation.
> 
> Am 18.07.13 20:15, schrieb Chuck Thier:
>> I think you are missing the point.  What I'm talking about is who
>> chooses what data is EC and what is not.  The point that I am trying to
>> make is that the operators of swift clusters should decide what data is
>> EC, not the clients/users.  How the data is stored should be totally
>> transparent to the user.
>> 
>> Now if we want to down the road offer user defined classes of storage
>> (like how S3 does reduced redundancy), I'm cool with that, just that it
>> should be orthogonal to the implementation of EC.
>> 
>> --
>> Chuck
>> 
>> 
>> On Thu, Jul 18, 2013 at 12:57 PM, John Dickinson <me at not.mn
>> <mailto:me at not.mn>> wrote:
>> 
>>    Are you talking about the parameters for EC or the fact that
>>    something is erasure coded vs replicated?
>> 
>>    For the first, that's exactly what we're thinking: a deployer sets
>>    up one (or more) policies and calls them Alice, Bob, or whatever,
>>    and then the API client can set that on a particular container.
>> 
>>    This allows users who know what they are doing (ie those who know
>>    the tradeoffs and their data characteristics) to make good choices.
>>    It also allows deployers who want to have an automatic policy to set
>>    one up to migrate data.
>> 
>>    For example, a deployer may choose to run a migrator process that
>>    moved certain data from replicated to EC containers over time (and
>>    drops a manifest file in the replicated tier to point to the EC data
>>    so that the URL still works).
>> 
>>    Like existing features in Swift (eg large objects), this gives users
>>    the ability to flexibly store their data with a nice interface yet
>>    still have the ability to get at some of the pokey bits underneath.
>> 
>>    --John
>> 
>> 
>> 
>>    On Jul 18, 2013, at 10:31 AM, Chuck Thier <cthier at gmail.com
>>    <mailto: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
>>    <mailto: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 <mailto:chmouel at enovance.com>> wrote:
>>> 
>>>> On Thu, Jul 18, 2013 at 12:42 AM, John Dickinson <me at not.mn
>>    <mailto: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
>>    <mailto: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
>>    <mailto: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
>>    <mailto: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
>> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4082 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130718/25a6bf78/attachment.bin>