<div dir="ltr">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.<div>
<br></div><div style>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.</div>
<div style><br></div><div style>--</div><div style>Chuck</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 18, 2013 at 12:57 PM, John Dickinson <span dir="ltr"><<a href="mailto:me@not.mn" target="_blank">me@not.mn</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are you talking about the parameters for EC or the fact that something is erasure coded vs replicated?<br>
<br>
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.<br>
<br>
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.<br>

<br>
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).<br>

<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
--John<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Jul 18, 2013, at 10:31 AM, Chuck Thier <<a href="mailto:cthier@gmail.com">cthier@gmail.com</a>> wrote:<br>
<br>
> 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.<br>

><br>
><br>
> On Thu, Jul 18, 2013 at 8:11 AM, John Dickinson <<a href="mailto:me@not.mn">me@not.mn</a>> wrote:<br>
> 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.<br>

><br>
> --John<br>
><br>
><br>
><br>
><br>
> On Jul 18, 2013, at 2:50 AM, Chmouel Boudjnah <<a href="mailto:chmouel@enovance.com">chmouel@enovance.com</a>> wrote:<br>
><br>
> > On Thu, Jul 18, 2013 at 12:42 AM, John Dickinson <<a href="mailto:me@not.mn">me@not.mn</a>> wrote:<br>
> >>    * Erasure codes (vs replicas) will be set on a per-container basis<br>
> ><br>
> > I was wondering if there was any reasons why it couldn't be as<br>
> > per-account basis as this would allow an operator to have different<br>
> > type of an account and different pricing (i.e: tiered storage).<br>
> ><br>
> > Chmouel.<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>