Open Stack

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> 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> 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
>
>
> _______________________________________________
> 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/9b90d6e8/attachment.html>