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 jos...@piston.cc On 2011-05-31, at 9:08 AM, Michael Barton wrote: > On Tue, May 31, 2011 at 8:37 AM, Rostyslav Slipetskyy > <rslipets...@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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
