Open Stack

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
>