TASK [component-pack : Wait for bootstrap to come up

[arnaldovale]

We have installed Connections 7 with CP, using the quickstart scripts. After installing, we have not been able to access the orient me page, although connections is running apparently fine. All pods seem to be running in the CP kubernetes. This is the output if we run the playbook "setup component pack"" ansible_issue30322.txt

Any idea?

[sabrina-yee]

Hi @arnaldovale, the ansible log fails at the bootstrap part which is quite early in the CP deployment process so at this point only a small amount of CP pods has been installed. You can check by running: kubectl -n connections get pods

I'd suggest to check the bootstrap log for errors: kubectl -n connections logs -f $(kubectl -n connections get pods | grep bootstrap | awk {'print $1'})

[arnaldovale]

Hi. These are the outputs for the commands command1.txt command2.txt

[sabrina-yee]

At the end of command2.txt it says: Attempting to configure cnx-server.internal.cloudapp.net with Redis using master ip: proxy-server.internal.cloudapp.net curl: (6) Could not resolve host: cnx-server.internal.cloudapp.net

Please check if the Connections server is reachable at https://cnx-server.internal.cloudapp.net.

[arnaldovale]

Hi. The operator has done this test:

Is this enough to test it?

[stoeps13]

But Redis is accessing Connections from within Kubernetes. Kubernetes is using DNS (kube-dns) and ignores /etc/hosts, so when you test this, please do this from within the Redis Pod:

kubectl exec -it redis-server-0 -- bash    

bash-5.0$ ping cnx7-rh8.stoeps.home
PING cnx7-rh8.stoeps.home (10.0.22.62): 56 data bytes
ping: permission denied (are you root?)

bash-5.0$ curl -k -l https://cnx7-rh8.stoeps.home 
bash: curl: command not found

Ping does a DNS lookup and shows the right IP. curl is not installed in the Redis pods and ping not running, because it runs as non-root. For a name lookup test, this should be fine.

[arnaldovale]

Hi, This is the output for the ping command within the Redis pod

[sabrina-yee]

Nothing jumps out yet. I took another look at the files included so far, since the output of kubectl -n connections get pods (command1.txt) returned already running Connections pods, I believe this is an upgrade scenario and bootstrap-rbtrt failed.

Since it worked at the initial deployment, connectivity must've been working at one point. I'd suggest to make sure the following then run the install again:

1) K8s is in a good state, check by running: kubectl get nodes kubectl -n kube-system get pods

2) Connections up and running, verify it's accessible via browser

If bootstrap fails again, check error by running kubectl -n connections logs -f $(kubectl -n connections get pods | grep bootstrap | awk {'print $1'})

[arnaldovale]

Hello, its being so difficult to troubleshoot this by ourselves. Would it be possible to run a live remote session so you could try to figure out whats hapenning? I could organize this meeting. Thanks!

[sabrina-yee]

Hi @arnaldovale, the nature of the issue does not seem to be specific to the deployment automation so I'd recommend to create a support ticket so we can work together to troubleshoot the issue and get on a remote session if needed. Thanks.

[arnaldovale]

Hi @arnaldovale, the nature of the issue does not seem to be specific to the deployment automation so I'd recommend to create a support ticket so we can work together to troubleshoot the issue and get on a remote session if needed. Thanks.

Right. You mean a HCL support case?

[sabrina-yee]

Right. You mean a HCL support case?

Yes, that's right, thanks!