Open Stack

Well, since the pluggable ring idea *was* about this as well (I'm pretty sure, since I proposed it), maybe it's time to talk merkle trees ;)

I'll circle back with notmyname and see what makes sense for breaking up this discussion into manageable chunks.

Joshua McKenty
Piston Cloud Computing, Inc.
(650) 283-6846
joshua at piston.cc



On 2011-05-31, at 9:08 AM, Michael Barton wrote:

> On Tue, May 31, 2011 at 8:37 AM, Rostyslav Slipetskyy
> <rslipetskyy at yahoo.com> wrote:
>> The idea to make ring implementation pluggable seems nice.
>> At the same time I am thinking that many developers might not will feel
>> comfortable with modifying existing ring structure, since it *works*
>> :) Probably, the other viable option for allowing data location compliance
>> is to implement it outside of ring file structure (but maybe inside the
>> future Ring component/service).
>> As an example I look at how replication works, "If a replicator detects that
>> a remote drive is has failed, it will use the ring's “get_more_nodes”
>> interface to choose an alternate node to synchronize with." It seems that
>> "Ring#get_more_nodes" can be used in a similar manner to select alternative
>> nodes in other zones for storing objects once some of the zones are banned
>> for specific accounts.
>> - Rostik
> 
> Placement policies are (IMO) a replication problem more than a ring
> problem.  Well, there's a ring component, and it's a fair bit of work,
> but it's sort of straightforward.  The problem is that replication
> decisions aren't made per object, they're made per partition or per
> sub-partition, which can contain a lot of individual objects.
> 
> So you'd need to break things up by replication policy in addition to
> the groupings it already does, so like groups can be synced between
> the right peers.  Having several times as many groups to consider
> could slow replication down quite a bit.  That might prompt a
> replication rethink (merkle trees?).  All this has kept me scared
> enough to stay away from it.
> 
> I think the pluggable ring idea is more about having separate backends
> fronted by a single Swift installation, and that's a whole other
> discussion.
> 
> -- Mike Barton
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp