Node registration/connection issue on NUC: Apiserver uses wrong node IP from ETCD

[akshaylg0314]

When setting up the system on a NUC, I encountered a node registration and connection issue between the NodeAgent and the Apiserver. The flow and problem are as follows:

Flow:

Register the node from the NUC by running NodeAgent.
On RHIVOS, the Apiserver receives the node info and saves it to ETCD.
Apply a YAML from the NUC by running ./demo.sh (with RHIVOS IP in the curl command).
The Apiserver reports a nodeagent connection error.
ETCD node info (example):

`cluster/nodes/HPC
{"node_id":"HPC-0.0.0.0","hostname":"HPC","ip_address":"0.0.0.0", ...}

cluster/nodes/localhost.localdomain
{"node_id":"localhost.localdomain","hostname":"localhost.localdomain","ip_address":"192.168.10.100", ...}

nodes/0.0.0.0
HPC
nodes/192.168.10.100
localhost.localdomain
nodes/HPC
0.0.0.0
nodes/localhost.localdomain
192.168.10.100`

Root Cause (code):
The Apiserver fetches the node IP by simply taking the first key with the prefix nodes/:

// Find a node by IP address from simplified node keys pub async fn find_node_by_simple_key() -> Option<String> { ... if let Some(kv) = kvs.first() { let ip_address = kv.key.trim_start_matches("nodes/"); return Some(ip_address.to_string()); } ... }
This means it may use the wrong node IP (e.g., 0.0.0.0 instead of the real node IP), causing connection errors.

Expected:

The Apiserver should select the correct node IP (matching the actual node or the one specified in the YAML/scenario), not just the first one in ETCD.
Actual:

The Apiserver may use 0.0.0.0 or another incorrect IP, leading to nodeagent connection errors.

[akshaylg0314]

Hey @daeyoung-jeong-lge @youngtaekiim
I raised the issue please check it once
Thanks!!

[daeyoung-jeong-lge]

The demo.sh is :

[lge@localhost examples]$ cat demo.sh
#!/bin/bash

#BODY=$(< ./resources/helloworld.yaml)
#BODY=$(< ./resources/adas-emergency.yaml)
BODY=$(< ./resources/adas-manual.yaml)
#BODY=$(< ./resources/adas-autonomous.yaml)
curl --location 'http://192.168.10.22:47099/api/artifact' \
--header 'Content-Type: text/plain' \
--data "${BODY}"

[youngtaekiim]

I think you are right. But this function called once in apply_artifacts().
And this is last method for get any node.
So, I think that fix is not necessary

[daeyoung-jeong-lge]

@akshaylg0314 @basheerFZ Actually, this is just phenomenon. There's a root cause of this. So we will fix the root cause of this and also we will change the failover strategy that go to 0.0.0.0 when everything is N/A. Because we have a bunch of things to do in 1Q 2026, this issue is supposed to be fixed in 2Q 2026. We will remain this issue to be opened until the fix is made.