[
https://issues.apache.org/jira/browse/HDDS-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136370#comment-18136370
]
Devesh Kumar Singh commented on HDDS-17526:
-------------------------------------------
[~anuragparvatikar] thanks for raising these concerns. Here is my understanding:
1. IMO, those legacy pipelines (with no tier aware) should not be stay open
indefinitely and we cannot just assume that with null storage tier for those
before finalization legacy pipelines are with DNs having only disks. Could be
those mapped DNs have SSD volumes, so I think we can extend the
PipelineManagerImpl.scrubPipelines() to gradually close these pipelines after
finalization, with a grace period and a limit on closures per cycle. This would
allow existing writes to complete while gradually freeing pipeline slots for
tier-aware pipelines. We should reuse the existing pipeline close/delete
lifecycle, not abruptly closing the pipelines, else container can be in
QUASI_CLOSED. *One important point to check if those null legacy pipelines can
still serve the requests for legacy allocations after storage policy
finalization ?*
2. *Agreed*. Since Pipeline and ContainerInfo persist StorageTier in SCM, and
DataNodes persist storageType in the .container YAML, we should introduce a new
HDDSVersion to protect these persistence changes.
Before HDDS finalization, SCM and DataNodes should preserve the legacy on-disk
representation and allocation behavior. After finalization, tier-aware
pipeline/container creation and persistence can be enabled.
We should gate both the feature behavior and serialization paths to ensure the
new fields are not accidentally persisted before finalization.
Since SCM and DataNodes share HDDSVersion, one feature version should be
sufficient for these changes. OM bucket/key policy persistence will be gated
separately using OzoneManagerVersion.
3. I suggest preserving the legacy volume-selection behavior where
(storageType=null, allowing any eligible volume) until HDDS finalization. After
finalization, we can apply hdds.datanode.default.storagetype (DISK by default)
when no explicit storage type is provided.
These are all impacts we are seeing after ZDU. cced: ZDU team ([~zitadombi],
[~erose], [~sodonnell]).
[~kkasawa]
> ZDU Impact on Storage Policy Feature [HDDS-11233]
> -------------------------------------------------
>
> Key: HDDS-17526
> URL: https://issues.apache.org/jira/browse/HDDS-17526
> Project: Apache Ozone
> Issue Type: Improvement
> Components: Ozone Datanode, Ozone Filesystem, Ozone Manager, Ozone
> Recon
> Reporter: Devesh Kumar Singh
> Assignee: Devesh Kumar Singh
> Priority: Major
> Attachments: Storage_Policy_ZDU_Design_with_Jira_Subtasks_v3.md
>
>
> The Storage Policy feature in HDDS-11233 is under development and started
> before the upstream zero-downtime upgrade (ZDU) framework was merged in
> master. The feature branch currently declares
> BUCKET_STORAGE_POLICY_SUPPORT(12) in the legacy OMLayoutFeature enum, and
> some OM request validators use that legacy value. After incorporating
> upstream ZDU, migrate this feature to the new component-version framework and
> establish explicit, testable compatibility boundaries for all components
> participating in policy metadata handling and physical data placement.
> OM must not persist or activate unsupported storage-policy metadata before
> the appropriate finalization. Clients and S3 Gateway must negotiate the
> capability of the receiving OM and preserve legacy behavior. SCM must
> validate policy-aware allocation, recovery and move capabilities
> independently of OM finalization; DataNodes must not silently ignore or
> misapply explicit storage-type requests. RATIS/EC repair, Container Balancer
> and Disk Balancer must maintain the documented strict/fallback placement
> contract. Recon and operational tooling must remain compatible with
> mixed-version metadata and report actionable failures.
> Deliver the implementation changes, version/field compatibility contract, and
> mixed-version unit/integration tests. Do not assume that ZDU finalization,
> Protobuf field acceptance, or RPC success proves actual physical placement
> compliance. Verify exact source paths and version numbers against the merged
> HDDS-11233 working tree.
> *Acceptance criteria:*
> * Storage Policy is registered through the correct post-ZDU OM
> component-version sequence, with an explicit decision for any persisted
> legacy feature-branch layout 12 state.
> * Pre-finalization OM operations preserve legacy behavior and do not persist
> new incompatible policy state; explicit-policy request handling is agreed and
> tested.
> * Client/S3G and each server boundary use appropriate negotiated capability
> checks and authoritative server-side enforcement.
> * Strict and allowed-fallback semantics are consistent across allocation,
> RATIS/EC repair, balancing and actual DataNode volume selection.
> * Mixed-version upgrade, restart, replay, snapshot, HA failover and
> downgrade-before-finalization scenarios pass, or have explicitly documented
> unsupported states.
> * Recon and operational signals remain usable throughout rollout;
> implementation and tests are linked to the corresponding tickets.
> cc: [~umamaheswararao] [~kkasawa] [~anuragparvatikar]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
