mirror of
https://github.com/rustfs/rustfs.git
synced 2026-09-01 01:38:18 +00:00
Zhengchao An
75cd3885f3
TierAzure.storage_class and .sp_auth round-trip faithfully through the admin API and on-disk config (ExternalTierAzure encode/decode in tier.rs), so an operator can configure them, read them back via ListTier, and never learn they do nothing. They are dropped only at the WarmBackendAzure construction boundary: the Azure warm backend goes through the same S3-compatible TransitionClient as every other provider and has no Azure Blob-native client or Azure AD dependency (confirmed: no azure_* crate anywhere in the workspace), so neither field can actually be honored today. MinIO's reference implementation (cmd/warm-backend-azure.go) treats both as first-class: storage_class sets the blob access tier on every PUT, and sp_auth is a full alternative to access/secret-key auth via azidentity, mutually exclusive with it. Rather than the larger, riskier options (add a native Azure SDK dependency and a parallel non-S3 client path, or break the persisted config format by removing the fields), this closes the silent-failure gap with the minimal safe fix: TierConfigMgr::add now rejects an Azure tier config with either field set, before backend construction, returning ERR_TIER_INVALID_CONFIG with an explicit message instead of accepting and ignoring. The fields stay in the config type (no format break); already-persisted tiers with these fields set are grandfathered in un-rejected (edit does not touch sp_auth or storage_class either). Full support remains a larger follow-up if ever prioritized. Also removes TierAzure::is_sp_enabled(), which had zero callers repo-wide (backlog#2055 flagged this) and would have been misleading dead weight once this decision was made — reusing it for the new gate would also have been wrong, since it requires *all three* sp_auth fields non-empty (&&), while the gate must reject on *any* one being set. Refs rustfs/backlog#2055 (cherry picked from commit 8d148c4e9b2507a1c5075e3d9513adb8b5851ef5)