jojochuang commented on PR #11053: URL: https://github.com/apache/ozone/pull/11053#issuecomment-5786270793
## Future: FSO buckets and Object Lock We may need to support **FILE_SYSTEM_OPTIMIZED (FSO)** buckets eventually. The current OEP correctly scopes v1 to **OBS**, but it would help to add a short **“Future: FSO”** note so readers do not assume OBS handlers generalize for free. **FSO is not natively compatible with the same WORM story as flat OBS keys.** AWS Object Lock is S3-object/version oriented; FSO adds a **file/directory split**, **path-based identity**, **rename**, **recursive/batch delete**, and **background purge** (`DirectoryDeletingService`, `OMDirectoriesPurgeRequestWithFSO`, etc.). Several of those paths have **no AWS S3 analogue**, so product and compliance rules need explicit decisions before implementation. ### Design decisions to make - **Scope of lock:** Files only (`FileTable` / `OmKeyInfo`) vs directory entries (`DirectoryTable` / `OmDirectoryInfo`). - **Clients:** S3G only vs also **OFS/Ozone FS** (rename/delete/overwrite bypass S3 action mapping unless OM enforces WORM on every RPC). - **Rename / move:** Block when locked vs allow and **carry** lock metadata on the same `objectID`; rename-over-existing-key vs Put overwrite rules. - **Tree delete:** Prefix delete when a descendant is locked; align partial failure with `DeleteObjects` semantics. - **Legacy FSO** buckets vs current FSO layout before allowing `objectLockEnabled`. ### Engineering pointers (when FSO is in scope) 1. **Duplicate handler surface:** WORM must be wired into **`*WithFSO`** create/commit/delete/MPU paths and **`OMFileCreateRequestWithFSO`**, not only OBS `OMKey*Request`. A shared **`WormPolicyEvaluator`** (or similar) reduces risk of one missed handler becoming a bypass. 2. **Background jobs are high risk:** Directory/key **purge and pending-deletion** services must respect lock state; async purge must not delete locked files under “deleted” directory markers. 3. **Rename:** `OMKeyRenameRequestWithFSO` / batch rename — treat as first-class WORM surface (DELETE+CREATE ACL-wise; compliance impact if rename is allowed without policy). 4. **Enforcement authority:** **OM `validateAndUpdateCache`** (and equivalent on FSO handlers) should remain authoritative; Ranger governs lock **administration** and governance **bypass**, not replacement for metadata checks on OFS clients. 5. **Testing:** FSO-specific integration — tree delete with one locked file, rename, MPU on paths, purge service, optional o3fs if in scope. Suggest a brief **Non-goal today / Future work** subsection in the OEP pointing here so OBS v1 can ship without implying FSO is a small delta. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
