NXBT-2865: add es dep check #5
Conversation
| initContainers: | ||
| - name: init-elasticsearch | ||
| image: busybox | ||
| command: ['sh', '-c', 'until wget -O/dev/null -q {{ .Release.Name }}-elasticsearch-client:9200 2>/dev/null; do echo waiting for {{ .Release.Name }}-elasticsearch-client; sleep 2; done;'] |
There was a problem hiding this comment.
rather look at a health check status for effective availability (also usually more efficient and reliable)
https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html
There was a problem hiding this comment.
I think here we just want to check for the dns and not introduce dependency on the way the service is configured (port or protocol or health)
a simple nslookup is enough, the healthness is testd by the readiness of the elasticsearch service that is using the es health status.
note also that check using busybox image and nslookup requires specific version to work properly (1.28)
docker-library/busybox#48 -> kubernetes/website#9901
There was a problem hiding this comment.
- nslookup is not practical due to the service being up and resolvable even though the pods are not yet in a ready state.
- as for the health, yes we could do that but once Nuxeo has access to ES it can read the cluster status and will mention it in its logs.
There was a problem hiding this comment.
yes so it sucks, k8s resolves the service name while it is not READY.
The readinessprobe logic must be duplicated in the nuxeo deployment initContainers.
Using elastic health state is better, even if nuxeo is waiting for the non red state it will fail faster in case of pb and we will not take the risk of exceeding the nuxeo es timeout.
There was a problem hiding this comment.
So in the end it looks like that K8s service ports are open only once the service is ready (the readiness probe of the service is successful), so we can just use "nc -w1 service port" to wait for the service, see next pr.
No description provided.