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