refactor(storage): hide replication runtime handles (#4152)

This commit is contained in:
Zhengchao An
2026-07-02 00:40:42 +08:00
committed by GitHub
parent 14016dbe8c
commit 572a001f93
6 changed files with 175 additions and 28 deletions
@@ -20,7 +20,7 @@ External `rustfs_ecstore::api` imports must stay in these local boundary files:
| Boundary file | Current facade families |
|---|---|
| `rustfs/src/storage/storage_api.rs` | Broad RustFS storage owner bridge for admin, bucket, capacity, client, compression, cluster, config, data usage, disk, error, event, global bootstrap controls, runtime-source getters, layout, metrics, notification, rebalance, rio, rpc, set disk, storage, and tier. |
| `rustfs/src/storage/storage_api.rs` | Broad RustFS storage owner bridge for admin, bucket, capacity, client, compression, cluster, config, data usage, disk, error, event, global bootstrap controls, runtime-source getters, layout, metrics, notification, rebalance, rio, rpc, set disk, storage, and tier. Replication pool/stat handles are projected into RustFS-local wrapper types here. |
| `crates/scanner/src/storage_api.rs` | Scanner bridge for bucket lifecycle, replication, metadata, capacity, config, data usage, disk, error, runtime, set disk, storage, and tier. Replication queue config, admission, and heal object DTOs are projected into scanner-local types here. |
| `crates/obs/src/metrics/storage_api.rs` | Metrics bridge for bucket bandwidth, lifecycle, replication, quota, capacity, data usage, error, runtime, and storage. |
| `crates/iam/src/storage_api.rs` | IAM bridge for config, error, notification, runtime, and storage. |
@@ -126,6 +126,9 @@ Current coupling:
- app object and multipart writes call object-replication boundary helpers
instead of constructing replication work DTOs or choosing object replication
operation types at the use-case layer;
- RustFS runtime consumers receive replication pool/stat handles through
storage-owner wrapper types instead of carrying ECStore replication handles
through app, admin, startup, or workload-admission layers;
- global replication pool/stat initialization still lives with ECStore runtime
compatibility state;
- modules inside `bucket/replication` use local relative paths rather than the
@@ -193,6 +196,10 @@ Required contracts before crate movement:
metrics through obs-local snapshot DTOs in
`crates/obs/src/metrics/storage_api.rs` instead of carrying the ECStore
replication stats handle through collectors.
- `ReplicationPoolHandle` / `ReplicationStatsHandle`: RustFS app, admin,
startup, and workload-admission code use storage-owner wrapper types from
`rustfs/src/storage/storage_api.rs` for pool activity, resync, queue counts,
proxy stats, and site metrics snapshots.
- `ReplicationScannerBridge`: scanner-originated replication heal scheduling is
exposed through the contract type in
`crates/ecstore/src/bucket/replication/replication_scanner_bridge.rs`.
@@ -174,8 +174,10 @@ Required evidence before proposing the split:
Decision: do not split in code yet. Replication remains coupled to ECStore
object APIs, bucket target clients, metadata systems, file metadata replication
state, runtime replication pool/stat handles, bucket monitor state, scanner
repair classification, lifecycle-originated deletes, and notification events.
state, ECStore-owned runtime replication pool/stat handles, bucket monitor
state, scanner repair classification, lifecycle-originated deletes, and
notification events. RustFS-facing runtime consumers should use storage-owner
wrapper handles while that state remains in ECStore.
Required evidence before proposing the split: