Dynamically changing user context

[as51340]

Hi,

I am using NuRaft within Kubernetes. Each of my servers get ClusterIP DNS entry which I use to start raft servers. Additionally to that, each of my servers need to be accessible from outside K8s cluster. Because of that, I wanted to make use of user_ctx. The hard part is that I will find out external IP of each server when I add it to the cluster. Is this a good use-case for user_ctx? Do you have some other recommendation for what I should use for storing a config related to each server. aux of srv_config seems to be immutable so I cannot use that. I also thought about adding my custom log in which additional information about each server would be written but not sure if this is a good pattern to have in custom logs written something that's very connected to cluster configuration.

Thanks for the help

[greensky00]

srv_config::aux_ is actually mutable, similar to priority_, but currently there is no external interface to modify it once a server is added. The only way to modify it is removing and re-adding server with new aux_ context. I think this is not what you want.

You can use user_ctx for that (storing additional IP for each server) purpose; define your own data structure (like a map from server ID to each server's context), and serialize it to binary (string) and put it into user_ctx.

Please note that, even though there is an API to modify aux_ for each server, the outcome is the same as user_ctx_. The leader will replicate the new cluster config with either new aux_ or user_ctx_. So there is no need for concern.

[greensky00]

FYI, a new API for in-place update of server config has been added.

NuRaft/include/libnuraft/raft_server.hxx

Lines 615 to 630 in e5e6ac6

	/**
	* Update the server configuration, only leader will accept this operation.
	* This function will update the current cluster config
	* and replicate it to all peers.
	*
	* We don't allow changing multiple server configurations at once,
	* due to safety reason.
	*
	* Change on endpoint will not be accepted (should be removed and then re-added).
	* If the server is in new joiner state, it will be rejected.
	* If the server ID does not exist, it will also be rejected.
	*
	* @param new_config Server configuration to update.
	* @return `true` on success, `false` if rejected.
	*/
	bool update_srv_config(const srv_config& new_config);

[as51340]

tnx on update!