mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-23 12:49:04 +00:00
Zhengchao An
3ff250f1cd
backlog#1823 step 8, partial. The swift module carries 43 #[allow(dead_code)] attributes, most with a comment naming a consumer: "Used by handler", "Handler integration: GET container", "Used by handler and object.rs". Every one of them suppresses nothing. crates/protocols/src/lib.rs declares `pub mod swift`, and swift/mod.rs declares all 22 submodules `pub mod`, so every item is publicly reachable and dead_code never applied to it. Removing all 43 leaves the warning count at zero, in both the default and --features swift lanes. That is also why those comments survived. They assert who calls the item — a claim the compiler normally settles on its own — and the compiler had been silenced by the visibility chain. The rest of step 8 needs a decision this PR does not make. Downgrading the 22 submodules to `pub(crate) mod` does restore detection, and it surfaces 39 real items, 16 of them the whole of sync.rs: SyncConfig, SyncStatus, SyncQueueEntry, ConflictResolution and every function and constant around them, i.e. Swift container sync is built and never wired. But the `pub mod` chain is load-bearing. Six integration tests under crates/protocols/tests are separate crates that import the submodules directly (swift::quota, swift::slo, swift::symlink, swift::sync, swift::tempurl, swift::container), and the downgrade fails to compile them. Restoring dead-code detection for this module therefore depends on first deciding whether those tests move in-crate — which is a testing-strategy call, not a cleanup one. Verification: cargo check -p rustfs-protocols warning-free in the default lane and with --features swift (lib and --tests); clippy --features swift --lib --tests -D warnings clean; cargo nextest run -p rustfs-protocols --features swift 441 passed; make pre-commit exit 0. Ref rustfs/backlog#1823 (step 8).
OpenStack Swift API for RustFS
Swift-compatible object storage API implementation for RustFS.
Features
This implementation provides Phase 1 Swift API support (~25% of full Swift API):
- ✅ Container CRUD operations (create, list, delete, metadata)
- ✅ Object CRUD with streaming downloads (upload, get, head, delete)
- ✅ Keystone token authentication
- ✅ Multi-tenant isolation with secure SHA256-based bucket prefixing
- ✅ Server-side object copy (COPY method)
- ✅ HTTP Range requests for partial downloads (206, 416 responses)
- ✅ Custom metadata support (X-Object-Meta-, X-Container-Meta-)
Not yet implemented:
- ⏳ Account-level operations (statistics, metadata)
- ⏳ Large object support (multi-part uploads >5GB)
- ⏳ Object versioning
- ⏳ Container ACLs and CORS
- ⏳ Temporary URLs (TempURL)
- ⏳ XML/plain-text response formats (JSON only)
Enable Feature
Swift API is opt-in and must be explicitly enabled.
Build with Swift support:
cargo build --features swift
Or enable all protocol features:
cargo build --features full
Note: Swift is NOT enabled by default to avoid unexpected API surface changes in existing deployments.
Configuration
Swift API uses Keystone for authentication. Configure the following environment variables:
| Variable | Description |
|---|---|
RUSTFS_KEYSTONE_URL |
Keystone authentication endpoint URL |
RUSTFS_KEYSTONE_ADMIN_TENANT |
Admin tenant/project name |
RUSTFS_KEYSTONE_ADMIN_USER |
Admin username |
RUSTFS_KEYSTONE_ADMIN_PASSWORD |
Admin password |
API Endpoints
Swift API endpoints follow the pattern: /v1/AUTH_{project_id}/...
Account Operations
GET /v1/AUTH_{project}- List containersHEAD /v1/AUTH_{project}- Get account metadata (not yet implemented)POST /v1/AUTH_{project}- Update account metadata (not yet implemented)
Container Operations
PUT /v1/AUTH_{project}/{container}- Create containerGET /v1/AUTH_{project}/{container}- List objectsHEAD /v1/AUTH_{project}/{container}- Get container metadataPOST /v1/AUTH_{project}/{container}- Update container metadataDELETE /v1/AUTH_{project}/{container}- Delete container
Object Operations
PUT /v1/AUTH_{project}/{container}/{object}- Upload objectGET /v1/AUTH_{project}/{container}/{object}- Download objectHEAD /v1/AUTH_{project}/{container}/{object}- Get object metadataPOST /v1/AUTH_{project}/{container}/{object}- Update object metadataDELETE /v1/AUTH_{project}/{container}/{object}- Delete objectCOPY /v1/AUTH_{project}/{container}/{object}- Server-side copy
Architecture
The Swift API is implemented as a Tower service layer (SwiftService) that wraps the S3 service:
HTTP Request
│
▼
┌───────────────┐
│ SwiftService │ ← Routes /v1/AUTH_* requests
└───────┬───────┘
│
┌────┴────┐
│ │
▼ ▼
Swift S3 Service
Handler (fallback)
Key Components
- handler.rs - Main service implementing Tower's Service trait
- router.rs - URL routing and parsing for Swift paths
- container.rs - Container operations with tenant isolation
- object.rs - Object operations including copy and range requests
- account.rs - Account validation and tenant access control
- errors.rs - Swift-specific error types
- types.rs - Data structures for Swift API responses
Tenant Isolation
Swift containers are mapped to S3 buckets with a secure hash prefix:
Swift: /v1/AUTH_abc123/mycontainer
↓
S3 Bucket: {sha256(abc123)[0:16]}-mycontainer
This ensures:
- Complete tenant isolation at the storage layer
- No collision between tenants with similar container names
- S3-compatible bucket naming (lowercase alphanumeric + hyphen)
Documentation
See the docs/ directory for detailed documentation:
SWIFT_API.md- Complete API referenceTESTING_GUIDE.md- Manual testing proceduresCOMPLETION_ANALYSIS.md- Protocol coverage trackingCOPY_IMPLEMENTATION.md- Server-side copy documentationRANGE_REQUESTS.md- Range request implementation details
License
Apache License 2.0