-
Type: New Feature
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: BlobManager, Migration Service
-
Team:PLATFORM
In case of a badly configured blob provider/dispatcher that creates a shared storage situation, one may want to fix the configuration (afterward production data/blobs were created).
We need a migration to re-dispatch the blobs to the expected provider in case a blob provider/dispatcher configuration is rewritten to remove older bad configuration (that creates such share storage cases) which prevents new scalable GC implementation (NXP-28565) from running.
The typical use case is when someone uses the retention addon and configures both the default and the record blob provider to use the same bucket name and prefix. We end up with blobs from both default and record providers stored in the same location. This is not compliant and one may want to fix this situation by reworking the blob provider config to store record blob in their dedicated bucket (with object lock available) and then run such migration to re-dispatch the blob to their newly configured location (i.e. bucket name / prefix).
Such migration could also address the cases where we have both prefixed and unprefixed blob key references in the repository such as described in NXP-32308.
EDIT
After work done for NXP-32164, it is now possible to Full GC a repository with shared storage like described above.
However, since NXP-32180, blob providers with the docIdKeyStrategy (such as record one) are not GC.