HDDS-15765. Fail fast when --node-id is omitted for OM compact/defrag on an HA cluster

[chihsuan]

What changes were proposed in this pull request?

On an HA OM cluster, ozone repair om compact and ozone admin om snapshot defrag without --node-id do not fail cleanly; they hang for a long time before eventually timing out.

Root cause: with no --node-id/--service-id, OMNodeDetails.getOMNodeDetailsFromConf(conf, null, null) falls back to the base config key ozone.om.address, which in an HA deployment defaults to 0.0.0.0:9862. That default is the OM server bind address (bind to all interfaces) and is meaningless as a client target. Because it resolves to a non-null (but useless) address, the tool builds a valid-looking OMNodeDetails for 0.0.0.0 and proceeds to the RPC, which then retries in the Hadoop IPC retry loop and blocks.

This PR adds a fail-fast check in both CLI commands: when --node-id is omitted but the config defines an HA service (OmUtils.isServiceIdsDefined(conf)), the command exits immediately and asks the operator to specify --node-id, instead of resolving to 0.0.0.0. Each command reports the error with its own existing convention.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-15765

How was this patch tested?

• New unit tests TestCompactOMDB#testCompactHAWithoutNodeIdFailsFast and TestDefragSubCommand#testDefragHAWithoutNodeIdFailsFast
• Existing TestCompactOMDB, TestDefragSubCommand, and TestOMNodeDetails still pass, and checkstyle is clean.
• Manual end-to-end run on the compose/ozone-ha cluster (om1/om2/om3, service.ids=omservice):

Command	Before	After
ozone repair om compact --cf keyTable (no --node-id)	hangs until timeout	returns immediately: This is an HA OM cluster; specify --node-id ...
ozone admin om snapshot defrag (no --node-id)	hangs until timeout	returns immediately: Error: This is an HA OM cluster; specify --node-id ...
ozone repair om compact --cf keyTable --service-id omservice --node-id om3	issues request	unchanged: Compaction request issued for om.db of om node: om3
ozone admin om snapshot defrag --service-id omservice --node-id om3	reaches om3:9862	unchanged: reaches real om3:9862 (not 0.0.0.0)

Generated-by: Claude Code (Opus 4.8)

[rich7420]

LGTM! thanks for the patch

[sreejasahithi]

Thanks @chihsuan for fixing this

1. CommandLine descriptions or the --help text for both commands does not mention the HA --node-id requirement.
   It would be better to add there as well.

2. Should HA nodeId validation failure exit non-zero, or is exit 0 ok here?

[adoroszlai]

2. Should HA nodeId validation failure exit non-zero, or is exit 0 ok here?

Good point.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[chihsuan]

Thanks for raising this! @sreejasahithi

1. CommandLine descriptions or the --help text for both commands does not mention the HA --node-id requirement.
   It would be better to add there as well.

Sounds good! I updated the --node-id descriptions for both commands in e6758ff.

2. Should HA nodeId validation failure exit non-zero, or is exit 0 ok here?

Yeah, I agree. I considered returning a non-zero value, but the existing OMNodeDetails validation returns exit code 0, so I kept the new validation consistent. I can change it in this PR if you prefer; otherwise, we can address exit codes consistently in a follow-up. What do you think?