redpanda
redpanda copied to clipboard
Better logging when Rejecting join request from node
Who is this for and what problem do they have today?
On-prem users typically do re-use a node that used to be part of another Redpanda cluster. Without wiping out the data directory, the new Redpanda cluster rejects the request with
Rejecting join request from node {id: 38639, kafka_advertised_listeners: {{:{host: 10.0.0.0, port: 9092}}}, rpc_address: {host: 10.0.0.0, port: 33145}, rack: {nullopt}, properties: {cores 12, mem_available 0, disk_available 0}, membership_state: active}, logical version -1 < 3
For better usability, the logging should be more descriptive to make required action clear.
What are the success criteria?
When the logical version a new host has doesn't match, we should advise what to do:
- Ask if the node was part of another cluster
- If that's the case, ask to wipe out the data dir
- If that's not the case, any possible reasons?
Why is solving this problem impactful?
For better usability and supportability