Hello ClearML community,
I’m having an issue in upgrading my ClearML helm chart from version 4.2.1 -> 7.2.2. The problem seems to stem from the way init containers make network requests to services like Elasticsearch, MongoDB, and Redis, as depicted in the helm charts apiserver-deployment.yaml
, fileserver-deployment.yaml
, and webserver-deployment.yaml
.
In my setup, I’m utilizing Istio to proxy requests and provide encryption in transit. Consequently, services like Elasticsearch, MongoDB, and Redis, that are deployed by the chart, are not directly reachable from an init container. This is resulting in a failure to start these deployments.
Here’s an example of the problem, as seen in the apiserver-deployment.yaml
file:
initContainers:
- name: init-apiserver
image: "{{ include "registryNamePrefix" (dict "globalValues" .Values.global "imageRegistryValue" .Values.apiserver.image.registry) }}{{ .Values.apiserver.image.repository }}:{{ .Values.apiserver.image.tag }}"
command:
- /bin/sh
- -c
- >
set -x;
{{- if .Values.elasticsearch.enabled }}
while [ $(curl -sw '%{http_code}' "http://{{ include "elasticsearch.servicename" . }}:{{ include "elasticsearch.serviceport" . }}/_cluster/health" -o /dev/null) -ne 200 ] ; do
echo "waiting for elasticsearch" ;
sleep 5 ;
done ;
{{- end }}
...
below is a proposed solution which adds an option in the chart’s values.yaml to allow disabling these checks when deploying in an environment where services are not directly accessible. This would allow the flexibility for users who are using service meshes or other network topologies where direct access may not be possible. Here’s a rough example of how that could be implemented:
{{- if not .Values.disableInitCheck }}
initContainers:
...
{{- end }}
This will essentially bypass the init container’s check for the services, and allow for the deployment to continue as expected. I’m wondering if i can submit a PR for this change and also looking to see if there is a different way one might solve this problem?