RATIS-2082. setConfiguration should not ignore address changes of existing peers

[smengcl]

Generated-by: Claude Code (Opus 5.5)

What changes were proposed in this pull request?

A setConfiguration request with the same peer IDs and priorities but different addresses is treated as "no change", so the addresses stored in the Raft log and raft-meta.conf can never be updated.

RaftConfigurationImpl.hasNoChange compares only IDs and priorities. This patch adds an overload that also compares peer addresses and uses it in setConfigurationAsync. RaftPeer.equals is not changed.

Running servers keep their existing connections. The new addresses are used after a restart.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/RATIS-2082

How was this patch tested?

Added RaftReconfigurationBaseTest.testAddressChangeRequest.

testNoChangeRequest now sends the peers of the current configuration, since cluster.getPeers() returns bind addresses that differ from the configured ones.

🤖 Generated with Claude Code

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

4 open findings

• The new overload introduces a boolean parameter that changes semantic behavior, which can be… · New
• The production change compares not only getAddress() but also getAdminAddress(),… · New
• This test hard-casts the storage to RaftStorageImpl, which tightly couples the test to a specific… · New
• Passing a literal boolean here makes the intent easy to miss and creates a 'boolean trap'. Consider… · New

What changed in this PR

Fixes setConfiguration so that changes to peer addresses (with the same peer IDs/priorities) are not incorrectly treated as “no change”, allowing updated addresses to be committed to the Raft log and persisted to raft-meta.conf.

Changes:

• Add an address-aware hasNoChange(...) overload in RaftConfigurationImpl and use it from RaftServerImpl.setConfigurationAsync.
• Update the “no change” reconfiguration test to send the actual configured peers rather than bind addresses.
• Add a new test that verifies address-only updates are committed and persist across restart.

File	Description
ratis-server/​src/​main/​java/​org/​apache/​ratis/​server/​impl/​RaftServerImpl.java	Makes setConfigurationAsync treat peer-address differences as a real config change.
ratis-server/​src/​main/​java/​org/​apache/​ratis/​server/​impl/​RaftConfigurationImpl.java	Adds optional address comparison to “no change” detection logic.
ratis-server/​src/​test/​java/​org/​apache/​ratis/​server/​impl/​RaftReconfigurationBaseTest.java	Adds coverage for address-only config updates and adjusts existing “no change” test input.

🧠 Review effort: Lite

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.

[szetszwo]

@smengcl , Updating address in runtime is tricky in general. When the peers do not have the correct addresses at startup, how are they supposed to talk to each others?

[smengcl]

@smengcl , Updating address in runtime is tricky in general. When the peers do not have the correct addresses at startup, how are they supposed to talk to each others?

@szetszwo Thanks for taking a look. The use case is the Ozone IPv6 work (HDDS-15763, design in apache/ozone#10981), which I should have mentioned earlier.

An existing SCM or OM HA group may have IPv4 literal peer addresses stored in the Raft log and raft-meta.conf. To move such a group to IPv6 without recreating it (HDDS-16136), the plan is:

1. Start IPv6 listeners on all peers while the IPv4 addresses stay reachable. The group keeps running on the old addresses.
2. Send one setConfiguration with the same peer IDs and the new IPv6 addresses, and wait for it to commit.
3. Update the Ozone configuration and restart the peers, then remove the IPv4 addresses.

Step 2 does not work today. The request returns success but nothing is written, so the IPv4 addresses stay in the stored configuration.

---

On your question, the peers always have working addresses at startup in this procedure, because the old addresses stay reachable until the new ones are committed and the peers have been restarted. This patch is not meant to repair a group whose peers cannot reach each other. Without a leader the request cannot be committed, and the offline raftMetaConf command is still the way to fix that.

The patch also does not change the connections of running servers. PeerProxyMap keeps the address it already has for a peer ID.

[szetszwo]

... restart the peers ...

If restarting is needed, could we just use raftMetaConf command (RaftMetaConfCommand)?

Using setConf may have some unnecessary complication since there are two addresses for the same peer at the same time. I am not sure if the code can handle them correctly.

[smengcl]

... restart the peers ...

If restarting is needed, could we just use raftMetaConf command (RaftMetaConfCommand)?

Using setConf may have some unnecessary complication since there are two addresses for the same peer at the same time. I am not sure if the code can handle them correctly.

@szetszwo Thanks, that is a fair concern, and I agree that changing addresses at runtime is tricky. To be clear about the scope: this patch only changes what is recorded. It does not change which addresses running servers connect to.

What it does: Today a setConfiguration with the same IDs and priorities but different addresses gets a success reply while the request is discarded, because hasNoChange compares only IDs and priorities. With the patch it is committed and written by every peer like any other configuration.

What it does not do: With gRPC, running servers keep their connections. PeerProxyMap keeps the first address it has for a peer ID, and the lookups in RaftConfigurationImpl, the majority checks and the log appenders all go by peer ID. The recorded addresses are reported to clients, for example in GroupInfo. A server uses a recorded address only for a peer it has no address for yet, for example when it starts without peers in its group and reads them from Raft storage.

Two addresses for the same peer: I believe this can already happen on master. A request that changes membership or priority and also has a different address for an existing peer already creates a joint configuration with both addresses, since the new configuration is built from the peers in the request. So the patch should not add a new state. It only stops skipping the case where nothing else changed.

I agree raftMetaConf is a reasonable option when a restart is needed anyway. I leaned towards setConfiguration for the Ozone case because Ozone SCM starts with an empty group and recovers its peers from Raft storage, so the stored addresses are what it uses after a restart. With setConfiguration that change is agreed by the group, instead of being edited by hand on each peer.

If it helps, I am happy to add tests for both behaviours: running servers keep working with the new addresses recorded, and servers restarted from storage use them. And if you still think the offline approach is the safer choice, I am fine with closing this and using raftMetaConf instead. Thanks for the careful review.