Skip to content

HDDS-15549. Recon's INITIAL_VERSION should not have an upgrade action - #10935

Merged
errose28 merged 2 commits into
apache:HDDS-14496-zdufrom
errose28:worktree/HDDS-15549-recon-initial-upgrade-action-2
Aug 17, 2026
Merged

HDDS-15549. Recon's INITIAL_VERSION should not have an upgrade action#10935
errose28 merged 2 commits into
apache:HDDS-14496-zdufrom
errose28:worktree/HDDS-15549-recon-initial-upgrade-action-2

Conversation

@errose28

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

The standard in the upgrade framework is that INITIAL_VERSION serializes to 0 and represents the state before any upgrade framework was introduced, meaning no version is found on disk. -1 is the in-memory serialized value representing an unknown/future version in the ComponentVersion framework.

  • Recon was using -1 as the in-memory placeholder to represent no version on disk, and then INITIAL_VERSION = 0 as the first version to introduce the upgrade framework. The creates a conflict with the standard versioning framework
  • Recon had an upgrade action tied to INITIAL_VERSION, which ran because initialization moved from version -1 to 0.

After #10443 switched Recon to the new versioning framework, Recon's initialization code now reads no version being present as the initial 0 version. The upgrade action tied to version 0 will not run. To fix this, we can merge version 0's upgrade action into version 1's upgrade action, so it will still run sequentially if upgrading to the current version from an old version before the versioning framework. Note that Recon's upgrade actions have been idempotent since #10442.

What is the link to the Apache JIRA

HDDS-15549

How was this patch tested?

  • TestInitialConstraintUpgradeAction was removed since its corresponding action was removed. Of the tests it contained:
    • testExecuteIsIdempotent is already covered by the existing idempotency test in TestReconTaskStatusTableUpgradeAction
    • testUpgradeAppliesConstraintModificationForAllStates is a general test of the constraint not specific to any upgrade action. It was moved to TestUnhealthyContainerReplicaMismatchAction which exclusively deals with the functionality, although it could optionally be duplicated in every action that updates this constraint.
    • testInsertionWithNullContainerState and testDuplicatePrimaryKeyInsertion were not testing the upgrade action or any Ozone code. They were testing existing SQL functionality of the library, so they were removed.

@github-actionsgithub-actionsBot added the zdu Pull requests for Zero Downtime Upgrade (ZDU) https://issues.apache.org/jira/browse/HDDS-14496 label Aug 3, 2026
@errose28
errose28 marked this pull request as ready for review August 4, 2026 17:53

@dombizitadombizita left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @errose28, looks good to me, the updateUnhealthyContainerStatesConstraint is running in the version 1's upgrade action, the removed code makes sense.

@errose28
errose28 merged commit 37874d1 into apache:HDDS-14496-zduAug 17, 2026
103 of 104 checks passed
errose28 added a commit to errose28/ozone that referenced this pull request Aug 17, 2026
* HDDS-14496-zdu:
HDDS-16153. DatanodeDetails should use HDDSVersion instead of int (apache#10994)
HDDS-15549. Recon's INITIAL_VERSION should not have an upgrade action (apache#10935)
HDDS-14753. Do not prematurely serialize client version (apache#10936)
HDDS-15885. SCM should validate software versions of peers before accepting finalize command (apache#10783)
HDDS-15641. SCM should send write pipeline version with DatanodeDetails on block allocation (apache#10878)
Conflicts:
hadoop-hdds/common/src/main/java/org/apache/hadoop/hdds/protocol/DatanodeDetails.java
hadoop-hdds/common/src/main/java/org/apache/hadoop/hdds/scm/pipeline/Pipeline.java
hadoop-hdds/common/src/test/java/org/apache/hadoop/hdds/protocol/TestDatanodeDetails.java
hadoop-hdds/container-service/src/main/java/org/apache/hadoop/ozone/HddsDatanodeService.java
hadoop-hdds/container-service/src/main/java/org/apache/hadoop/ozone/container/common/helpers/DatanodeIdYaml.java
hadoop-hdds/server-scm/src/main/java/org/apache/hadoop/hdds/scm/protocol/StorageContainerLocationProtocolServerSideTranslatorPB.java
hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/protocolPB/OzoneManagerProtocolClientSideTranslatorPB.java
hadoop-ozone/integration-test/src/test/java/org/apache/hadoop/ozone/client/rpc/TestBlockDataStreamOutput.java
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/file/OMRecoverLeaseRequest.java
errose28 added a commit to errose28/ozone that referenced this pull request Aug 21, 2026
* HDDS-14496-zdu:
HDDS-16154. Datanode should assign DatanodeDetails#currentVersion based on its apparent version (apache#11006)
HDDS-16153. DatanodeDetails should use HDDSVersion instead of int (apache#10994)
HDDS-15549. Recon's INITIAL_VERSION should not have an upgrade action (apache#10935)
HDDS-14753. Do not prematurely serialize client version (apache#10936)
HDDS-15885. SCM should validate software versions of peers before accepting finalize command (apache#10783)
HDDS-15641. SCM should send write pipeline version with DatanodeDetails on block allocation (apache#10878)
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

zduPull requests for Zero Downtime Upgrade (ZDU) https://issues.apache.org/jira/browse/HDDS-14496

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@errose28@dombizita