Storage Policy fallback?

[open-io]

Storage Policy fallback?

[jfsmig]

OK, let's propose something. Consider the configuration snippet below:

[STORAGE_POLICY]
5COPIES=NONE:DUP3:NONE
3COPIES=NONE:DUP5:NONE
ATBEST2COPIES=NONE:DUP1:NONE
EXACTLY2COPIES=NONE:DUP2:NONE
[DATA_SECURITY]
DUP5=DUP:distance=1|nb_copy=5:DUP3
DUP3=DUP:distance=1|nb_copy=3:DUP2
DUP2=DUP:distance=1|nb_copy=2
DUP1=DUP:distance=1|nb_copy=2:NONE

Let's consider you want to upload a content associated with the storage policy 5COPIES. The 5COPIES policy points to DUP5 security, with an allowed fallback to DUP3.

The content should be associated (in the container) with 5COPIES to reflect the initial intention of the client. So, if to few replicas are referenced in the container, a sanity crawler has enough information to find 2 additionnal services.

I propose the upload should fail if only 2 rawx services are available, because DUP2 is not an allowed fallback for DUP5. But the upload should succeed if 3 rawx are available because DUP3 is explicitely listed.

In other words, fallbacks should not be transitive.

Also, if a content is uploaded with the policy ATBEST2COPIES that points to DUP1, the fallback NONE is mentioned, so that the load-balancer is allowed to poll only 1 rawx.

Eventually, if a content is uploaded with the policy EXACTLY2COPIES that points to DUP2, no fallback is mentioned, so that the load-balancer will only accept a solution with exactly 2 services polled.

OK with this?

[jfsmig]

This should be easy to do in the short term, even if the "LB review plan" proposed in #190 still remains necessary.

[jfsmig]

Too complicated to be quickly changed.
An higher level LB evolution is considered not a priority.