Incorrect peer_addr in cluster_info meta table

[sunng87]

What type of bug is this?

Incorrect result

What subsystems are affected?

Distributed Cluster

Minimal reproduce step

select * from information_schema.cluster_info

What did you expect to see?

This peer_addr field has different implementation for different peer types.

• datanode is using --rpc-hostname parameter, which uses hostname of the node. This is preferred for displaying host address.
• metasrv seems to use its grpc connection's local address here, which need be corrected.
• frontend seems use its grpc servers' listening address here, which need be corrected.

Also we should not show grpc port here because on these three node types, grpc serves different purpose and its meaningless to list them together.

What did you see instead?

+---------+-----------+-------------------------------------------------------------------+---------+------------+----------------------------+-------------------+-------------+
| peer_id | peer_type | peer_addr                                                         | version | git_commit | start_time                 | uptime            | active_time |
+---------+-----------+-------------------------------------------------------------------+---------+------------+----------------------------+-------------------+-------------+
|      -1 | METASRV   | 10.244.0.25:3002                                                  | 0.8.1   | unknown    | 2024-06-20 13:41:04.339000 | 12h 22m 10s 857ms | NULL        |
|       0 | DATANODE  | greptimedb-datanode-0.greptimedb-datanode.greptimedb-cluster:4001 | 0.8.1   | unknown    | 2024-06-20 13:43:25.491000 | 12h 19m 49s 705ms | 2s 598ms    |
|       1 | DATANODE  | greptimedb-datanode-1.greptimedb-datanode.greptimedb-cluster:4001 | 0.8.1   | unknown    | 2024-06-20 13:42:52.340000 | 12h 20m 22s 856ms | 2s 764ms    |
|       2 | DATANODE  | greptimedb-datanode-2.greptimedb-datanode.greptimedb-cluster:4001 | 0.8.1   | unknown    | 2024-06-20 13:42:19.742000 | 12h 20m 55s 454ms | 2s 83ms     |
|      -1 | FRONTEND  | 0.0.0.0:4001                                                      | 0.8.1   | unknown    | 2024-06-20 13:43:27.032000 | 12h 19m 48s 164ms | 14s 947ms   |
+---------+-----------+-------------------------------------------------------------------+---------+------------+----------------------------+-------------------+-------------+
5 rows in set (0.006 sec)

What operating system did you use?

any

What version of GreptimeDB did you use?

HEAD

Relevant log output and stack trace

No response

[killme2008]

I think gRPC port is good because it exists in all three types of nodes. Other protocols such as HTTP does not.

[killme2008]

Also we should not show grpc port here because on these three node types, grpc serves different purpose and its
meaningless to list them together.

But in another meaning, they are serving the same purpose - gRPC requests, wherever they come from users or internal requests.

[killme2008]

The metasrv address is correct. It uses server_addr in metasrv configuration,which is the the communication server address for frontend and datanode to connect.

[sunng87]

But in another meaning, they are serving the same purpose - gRPC requests, wherever they come from users or internal requests.

One scenario I realized using port here may make sense is when multiple instances deployed on a single node, we use port as some sort of process id. I'm ok to keep it until we find better alternatives. We still need to explain the meaning of the ports when it's listed on cluster topology view.

[killme2008]

We can add a node_info table to list all the binding ports for a node.