Cluster V2 modularity options about valkey HOT 4 OPEN

The other half of the same struct is related to the cluster bus. Is it worth splitting the struct?

The current abstraction is that the clusterbus owns the underlying struct, and can define whatever implementation it wants for modifying the data. It just needs to provide a coherent external API for cluster.c. I'm not exactly sure how we would split it.

from valkey.

@PingXie Thoughts ^

from valkey.

Here are the cluster subcommands from commands.def

These are the subcommands that are flagged as CMD_ADMIN:

addslots 
addslotsrange 
bumpepoch 
count-failure-reports 
delslots 
delslotsrange 
failover 
flushslots 
forget 
meet 
replicas 
replicate 
reset 
saveconfig 
set-config-epoch 
setslot 
slaves 

These are the rest of the subcommands:

countkeysinslot
getkeysinslot
help 
info
keyslot
links
myid
myshardid
nodes
shards 
slots 

from valkey.

cluster_legacy.(c|h): These files include all of the code for maintaining the clusterbus and the internal topology it maintains. It will maintain the administration commands for manipulating that topology.

Half of the clusterNode struct is client facing information, like a node's name, its slots, IP, port, TLS port, it's replicas, etc. This information is often accessed from cluster.c for various client-facing commands.

The other half of the same struct is related to the cluster bus. Is it worth splitting the struct?

from valkey.