Skip to content
This repository has been archived by the owner on Aug 14, 2024. It is now read-only.

NXBT-2865: add es dep check #5

Closed
wants to merge 1 commit into from
Closed

NXBT-2865: add es dep check #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions nuxeo/templates/deployment.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,12 @@ spec:
mountPath: /var/log/nuxeo
- name: binaries
mountPath: /binaries
{{- if or .Values.elasticsearch.deploy .Values.tags.elasticsearch }}
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;']
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@bdelbosc bdelbosc May 17, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@ffjdm ffjdm May 17, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. nslookup is not practical due to the service being up and resolvable even though the pods are not yet in a ready state.
  2. 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.

Copy link
Member

@bdelbosc bdelbosc May 17, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@bdelbosc bdelbosc May 17, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#9

{{- end }}
securityContext:
fsGroup: 1000
volumes:
Expand Down