Can not list spaces with docker deployment

[caton-hpg]

./nebula-console-linux-amd64-v3.0.0 -addr=192.168.8.240 -port 9669 -u root -p nebula

(root@nebula) [(none)]> show meta leader
+---------------+---------------------------+
| Meta Leader   | secs from last heart beat |
+---------------+---------------------------+
| "metad0:9559" | 9                         |
+---------------+---------------------------+
Got 1 rows (time spent 443/1492 us)

LOG:

I0602 10:40:13.180270 23678 MetaClient.cpp:204] Send request to meta \"192.168.8.240\":9559
E0602 10:40:13.181121 23678 MetaClient.cpp:211] Send request to meta\"192.168.8.240\":9559 failed
E0602 10:40:13.181367 23613 MetaClient.cpp:82] List space failed
E0602 10:40:13.181386 23613 MetaClient.cpp:33] load data failed
E0602 10:40:13.181433 23613 MetaClient.cpp:42] Get space id for 美职篮球员 failed

[jinyingsunny]

nebula-cpp 3.0

[Shylock-Hg]

Is this issue of nebula-cpp?

[caton-hpg]

It's been a while.
I remembered, it's a docker environment. Its meta address is meta0, so the meta API cannot be called.
Maybe it's caused by a docker environment, not a nebula-cpp issue.

[Shylock-Hg]

It's been a while. I remembered, it's a docker environment. Its meta address is meta0, so the meta API cannot be called. Maybe it's caused by a docker environment, not a nebula-cpp issue.

Move this issue to its own repo.

[Shylock-Hg]

I think it's maybe a network problem. Try to ping meta host in graph host.

[caton-hpg]

But I used NebulaGraph in NebulaAnalytics. NebulaAnalytics is not in graph host.

[caton-hpg]

I reproduced this problem on version 3.3.0.

1. First, NebulaAnalytics will execute show meta leader and get meta address.

+---------------+---------------------------+
| Meta Leader     | secs from last heart beat    |
+---------------+---------------------------+
| "metad1:9559" | 2                                            |
+---------------+---------------------------+

2. Then, Get nebula partitions through meta address.

The metad1 is not real host name. So, Cannot get nebula partitions through "metad1:9559"

[Shylock-Hg]

I reproduced this problem on version 3.3.0.

1. First, NebulaAnalytics will execute show meta leader and get meta address.

+---------------+---------------------------+
| Meta Leader     | secs from last heart beat    |
+---------------+---------------------------+
| "metad1:9559" | 2                                            |
+---------------+---------------------------+

2. Then, Get nebula partitions through meta address.

The metad1 is not real host name. So, Cannot get nebula partitions through "metad1:9559"

As I known, docker compose will set host name to metad1

[Shylock-Hg]

I reproduced this problem on version 3.3.0.

1. First, NebulaAnalytics will execute show meta leader and get meta address.

+---------------+---------------------------+
| Meta Leader     | secs from last heart beat    |
+---------------+---------------------------+
| "metad1:9559" | 2                                            |
+---------------+---------------------------+

2. Then, Get nebula partitions through meta address.

The metad1 is not real host name. So, Cannot get nebula partitions through "metad1:9559"

Try to ping metad1.

[Shylock-Hg]

I can't reproduce with docker-compose cluster:

➜  nebula-console git:(master) ✗ ./nebula-console -u root -p nebula --address 127.0.0.1 --port 9661

Welcome to Nebula Graph!

(root@nebula) [(none)]> show spaces
+------+
| Name |
+------+
+------+
Empty set (time spent 2085/3857 us)

Wed, 04 Jan 2023 11:50:36 CST

(root@nebula) [(none)]>

Please verify your hostname settings.

[wey-gu]

I guess @caton-hpg meant he cannot use metaclient(cpp) to list spaces from the analytics process, where, the analytics process is sitting outside of the docker-compose network, thus it cannot resolve the metad0, metad1, metad2 hostname.

[wey-gu]

I guess @caton-hpg meant he cannot use metaclient(cpp) to list spaces from the analytics process, where, the analytics process is sitting outside of the docker-compose network, thus it cannot resolve the metad0, metad1, metad2 hostname.

If my guess is true, this is exactly the same issue we have when it comes to spark utils + containerized deployment of NebulaGraph.

https://github.com/vesoft-inc/nebula-cloud-platform/issues/141

cc @MuYiYong @HarrisChu @MegaByte875 @nianiaJR

And it's actually related to how we discover/identify service instances(with their configured my_ip+port), when meta/storage deamon need to be accessed by meta/storage clients outside of the cluster, the internal-only address will have issues, we need to revisit this(introduce a mapping mechanism? or introduce client side configurable meta-list/storage-list, which is against the cloud pattern though) or hack(as I provided in above issues: k8s, docker-compose or k8s+apigateway), or enable storage datascan via/proxied-from graphD

[Shylock-Hg]

Yes, deploy nebula by nebula-docker-compose, meta won't expose its port to host. So it can't be accessed outside docker network.