hani-fouladgar commented on PR #11218: URL: https://github.com/apache/ozone/pull/11218#issuecomment-5763956028
> Adding an SCM can fail if the node list is applied before it Thanks, that's a fair read — both cases are inherent to per-key validation, and I agree grouped/atomic validation of ozone.scm.nodes.<svc> together with the ozone.scm.address.<svc>.* keys is the clean fix. What this PR guarantees today is the safety property: an unresolvable node list fails and is rolled back (visible as FAILED, retriable), so the live configuration never ends up holding an SCM without an address, and getServiceList() stays consistent. The two residuals are usability, not correctness: - node-list-before-address needs the address set first (or a retry) — same two-pass behavior as the datanode, which skips an unresolvable add; - an unresolvable address-only change is logged and the previous proxies are kept, but the status still reads SUCCESS because a reconfiguration-complete callback can't fail the batch. Closing both properly means adding a batch/pre-validation hook to ReconfigurableBase/ReconfigurationHandler, which is shared by the datanode, OM, and SCM. Since that changes the shared mechanism, I agree it's better as a separate change with a committer's input rather than expanding this PR's scope. I'll file a follow-up HDDS Jira for grouped SCM-config validation and link it here — happy to take it on once there's a committer's steer on the approach. Does deferring those two cases to that follow-up sound reasonable for this PR? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
