-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
False
-
None
-
False
-
-
-
Submariner Sprint 2024-25, Submariner Sprint 2024-26, Submariner Sprint 2024-27, Submariner Sprint 2024-28, Submariner Sprint 2024-29
-
None
Description of problem:
I used ACM UI (2.11) to deploy Submariner on ROKS on Satelite clusters,
While one of the nodes marked as GW and submariner-addon runs on both spoke clusters as expected, IPSec connection status is not healthy, the GW pod logs complain that it cannot resolve the hostname of the Broker API server, check [1].
When comparing hostname of apiServerURL from infrastructure/cluster resource [2] to hostname of brokerK8sApiServer from submariner CR you can see that the values are different.
sd579c61a6bedc821faa3-6b64a6ccc9c596bf59a86625d8fa2202-ce00.jp-tok.satellite.appdomain.cloud:30263
vs
d579c61a6bedc821faa3-6b64a6ccc9c596bf59a86625d8fa2202-ce00.jp-tok.satellite.appdomain.cloud:30263
Seems that the root cause is this code
[1]
W0728 14:15:17.846752 1 reflector.go:547] github.com/submariner-io/admiral/pkg/syncer/resource_syncer.go:367: failed to register submariner.io/v1, Kind=Cluster: get "https : //d579c61a6bedc821faa3-6b64a6ccc9c596bf59a86625d8fa2202-ce00.jp-tok.satellite.appdomain.cloud:30263/apis/submariner.io/v1/names-sources/0faults: Verc p: lookup d579c61a6bedc821faa3-6b64a6ccc 9c596bf59a86625d8fa2202 -ce00.jp-tok.satellite .appdomain.cloud at 172.21.0.10:53: No such host
God
[2]
$ oc get infrastructure cluster -oyaml | grep apiServerURL:
apiServerURL: https://sd579c61a6bedc821faa3-6b64a6ccc9c596bf59a86625d8fa2202-ce00.jp-tok.satellite.appdomain.cloud:30263
[3]
$ oc get submariner -n submariner-operator submariner -oyaml | grep brokerK8sApiServer:
brokerK8sApiServer: d579c61a6bedc821faa3-6b64a6ccc9c596bf59a86625d8fa2202-ce00.jp-tok.satellite.appdomain.cloud:30263
- clones
-
ACM-12964 Submariner deployment fails if broker's apiserver hostname starts with one of h,p,s,t
- Closed
- links to
-
RHEA-2024:140484 RHEA: Submariner 0.18.2 - bug fix and enhancement update