Comparing the output of them,

I think deleting nodes only by ID is probably the best option.
Perhaps in a second PR we could update the output of show datanodes to include 
the InternalAddress and InternalPort?

I probably also should check if removing config nodes via ID works … because 
technically removing a datanode by Id didn’t work till my fix.

So, I think I should undo the parts I added for replacing the 0.0.0.0 with the 
internal address and double check the remove config-node code.

Chris

Von: Wang Critas <cri...@outlook.com>
Datum: Donnerstag, 25. Juli 2024 um 09:36
An: dev@iotdb.apache.org <dev@iotdb.apache.org>
Betreff: 答复: How to handle the internal and external IPs of Data-Nodes?
Hi Chris

Perhaps more often than not, show clusters are used?

Best
----------------
Xuan Wang
发件人: Christofer Dutz <christofer.d...@c-ware.de>
日期: 星期四, 2024年7月25日 15:31
收件人: dev@iotdb.apache.org <dev@iotdb.apache.org>
主题: AW: How to handle the internal and external IPs of Data-Nodes?
Hi all,

In that case we would need to show the internal ip in the show datanodes 
command, right?
Or would we simply expect the user to know the internal IP of the datanode he 
wants to remove?

Chris

Von: Wang Critas <cri...@outlook.com>
Datum: Donnerstag, 25. Juli 2024 um 08:16
An: dev@iotdb.apache.org <dev@iotdb.apache.org>
Betreff: 答复: How to handle the internal and external IPs of Data-Nodes?
Hi

Why not use nodeId or internalAddress:internalPort for unified behavior

Remove ConfigNode through nodeId or internalAddress:internamPort

Best
----------------
Xuan Wang

发件人: Xinyu Tan <tanxi...@apache.org>
日期: 星期四, 2024年7月25日 12:26
收件人: dev@iotdb.apache.org <dev@iotdb.apache.org>
主题: Re: How to handle the internal and external IPs of Data-Nodes?
Hi, chris

+1 for identifying nodes solely by nodeid

Best
----------------
Xinyu Tan

On 2024/07/24 14:33:20 Christofer Dutz wrote:
> Hi all,
>
> I’m currently working on 
> https://github.com/apache/iotdb/pull/12914<https://github.com/apache/iotdb/pull/12914><https://github.com/apache/iotdb/pull/12914%3chttps:/github.com/apache/iotdb/pull/12914%3e><https://github.com/apache/iotdb/pull/12914><https://github.com/apache/iotdb/pull/12914%3chttps:/github.com/apache/iotdb/pull/12914%3e%3chttps:/github.com/apache/iotdb/pull/12914%3chttps:/github.com/apache/iotdb/pull/12914%3e%3e%3chttps:/github.com/apache/iotdb/pull/12914%3e>
>
> Here one of the problems was, that in a cluster with 3 datanodes, where the 
> dn_rpc_address is set to 0.0.0.0, the command “show datanodes” lists each 
> node with an address of 0.0.0.0. So, if someone wants to remove a data-node 
> by its IP, the cli will not find the corresponding node as it thinks it’s 
> 0.0.0.0. However, if you use the cli to delete 0.0.0.0, then it deletes all 
> nodes.
>
> Now my initial fix for this, was, that if a data-node registers and says his 
> dn_rpc_address is 0.0.0.0, that instead of this, the IP from which we are 
> getting the request is being used (Obviously this one exists and belongs to 
> the data-node registering).
> The problem is that this usually will be the dn_internal_address instead of 
> the dn_rpc_address.
>
> Now we could use that instead, but I think it would reduce the usefulness of 
> the “show datanodes” command, because it could be in a cluster-internal 
> network, that the client can’t connect to.
> So, if a client wants to know which other data-nodes there are in order to 
> connect to another one, this might not be helpful.
> However, 0.0.0.0 is also not helpful, as I see no chance to be able to 
> connect to a data-node using 0.0.0.0:6667 as that’s not really a real Ip 
> address.
>
> So, I think, that possibly instead of maintaining 0.0.0.0 we should replace 
> this with the list of public IP addresses the data-node possesses. In this 
> case show data-nodes would no longer display only one IP-Address, but a list 
> of IP-Addresses.
>
> When removing a data-node (or sending any other commands to it) we could now 
> identify a particular data-node as only one will have the IP+Port combination.
>
> What do you think?
>
> Chris
>

Reply via email to