[jira] [Created] (RATIS-2765) Add a PeerNameService to resolve peer addresses

["Siyao Meng (Jira)" <ji...@apache.org>]

Siyao Meng created RATIS-2765:
---------------------------------

             Summary: Add a PeerNameService to resolve peer addresses
                 Key: RATIS-2765
                 URL: https://issues.apache.org/jira/browse/RATIS-2765
             Project: Ratis
          Issue Type: Sub-task
            Reporter: Siyao Meng


As discussed in [RATIS-2754|https://issues.apache.org/jira/browse/RATIS-2754?focusedCommentId=18129249&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-18129249], add a {{PeerNameService}} (similar to DNS) to manage peer addresses. RATIS-2754 will use it to refresh the stored peer addresses at startup.

The current addresses of a peer come from the startup peers. The old addresses are the ones replaced at startup. The service only changes at startup.

{{PeerNameService.resolve(RaftPeer)}}:
* If the addresses match the current addresses, return the peer.
* If they match old addresses, return the peer with the current addresses.
* If they are unset, return the peer with the current addresses.
* Otherwise, the addresses are unknown, see below.

Proposed details:
* All four addresses (address, admin, client and data stream) are resolved together. They change together, and gRPC falls back from an empty client or admin address to the address, so resolving them separately could mix new and old addresses.
* It is enabled only with {{raft.server.startup.refresh-peer-addresses.enabled}}. Otherwise {{resolve}} returns the peer unchanged.
* On the log path (appendEntries, applying entries, installing a snapshot), unknown addresses are kept with a warning. Throwing there would make a follower reject a log entry from the leader and get stuck. They do not become current either, since a follower handles a conf entry before it is committed, and the entry may be truncated.
* {{setConfiguration}} on the leader throws an exception for unknown addresses of a known peer, before the conf entry is appended, so the client gets the error.
* {{setConfiguration}} does not update the service. An address only change is already a no-op, since {{hasNoChange}} ignores addresses. To change addresses, update the startup peers and restart.

Possible follow up: {{PeerProxyMap.resetProxy}} reconnects to the first address it saw for a peer. Resolving there would let connections follow the current addresses (RATIS-2082). The proxy map belongs to the server rather than a group, so the service may belong to the server as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)