Open Stack

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