Node id assignment #1

This will be used when we first start a node that has no node UUID. I exposed this as storage because the UUID uniquely identifies the contents of the kv-store / data directory.

This encapsulates some pieces of cluster discovery into its own class. I added some descriptions on how each method is expected to be implemented, but I added implementations that match the existing behavior.

This adds the skeleton of an RPC service that will be used for cluster bootstrap. It includes an initial `cluster_bootstrap_info` RPC type that is currently empty. Introducing as a standalone commit to parallelize some workstreams.

This plumbs the cluster discovery module into `redpanda::application` as one of the first subsystems initialized during startup. Cluster discovery will have an initial dependency on the storage subsystem, to get node UUID, cluster UUID, etc., and on the RPC subsystem, to serve the RPCs required for the initial bootstrapping sequence. The rest of the subsystems will have a dependency on cluster discovery, which, once automatic node ID assignment is supported, will be what determines the node ID. To that end, this commit orders the startup of the storage and RPC subsystems up front, followed by cluster discovery, followed by the rest of the subsystems. This commit only plumbs cluster discovery infrastructure. The cluster discovery sequence as a whole is unchanged.

It can be convenient to construct a named_type using constructors of the underlying type. A simple solution today is to construct the underlying type separately and then construct the named_type with it, but this spills the underlying type into call sites. Another approach would be to construct with the named_type::type constructor, but this can be verbose. This commit adds a templatized static constructor that callers can pass constructor args into.

Upon first starting up the storage layer, Redpanda will now check to see if a node UUID exists in the controller keyspace of the key-value store. If not, it will generate one and persist it to disk, and make it available on all shards. This will be used as a unique identifier when registering a node (particularly important in the future when we auto-assign node IDs).

This adds a new controller command to register a node UUID. It is activated by the existing join RPC endpoint and has the following semantics: - Register: all new versions of Redpanda will send their UUID along with an optional node ID in their initial join request. If the UUID is not in the leader controller's `members_table`, the UUID is registered by replicating a `register_node_uuid_cmd`. - Join: all new version of Redpanda will, after registering, send another join request that will actually add the node to the Raft group. Old versions of Redpanda will send a join request with no UUID.

This commit makes the node_id config property optional. It doesn't make any checks that the field is set. A follow-up will change the Redpanda's behavior when seeing an empty node ID.

This commit adds the ability for Redpanda to assign node ID based on the node UUID when a node ID isn't set.

When the controller starts up, we check to ensure the configured node ID is identical to that in the kvstore if one exists, persisting one if not. We should use this node ID at startup if weren't configured with one, e.g. if we're upgrading an existing cluster and begin omitting node ID from the node config.

RPC `client_probe` metrics currently leverage a labeling scheme defined by Seastar in which, for a given metric, a set of metric labels can only be registered once per metric. Currently, the label used is solely based on the server address associated with a given `rpc::transport`. As such, we currently cannot start multiple `rpc::transport`s pointed at the same server. This functionality could be useful though: consider when a node is restarted empty with a new node ID. Redpanda currently has a check that nodes being added to the controller Raft group don't overlap with existing group members' addresses. But if we were to remove this check, when the new node _is_ added to the Raft group, each node will try to create a new `rpc::transport` pointing at the new node, and register metrics with identical labels to those registered by the old node, and be met with a Seastar `double_registration` exception. To enable the above scenario, this commit adds the `node_id` as a label for client metrics, and aggregates them by this label.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Node id assignment #1

Node id assignment #1

Commits on Oct 7, 2022

Node id assignment #1

Are you sure you want to change the base?

Node id assignment #1

Commits on Oct 7, 2022