Examples: query, "exact match", wildcard*, wild?ard, wild*rd
Fuzzy search: cake~ (finds cakes, bake)
Term boost: "red velvet"^4, chocolate^2
Field grouping: tags:(+work -"fun-stuff")
Escaping: Escape characters +-&|!(){}[]^"~*?:\ with \, e.g. \+
Range search: properties.timestamp:[1587729413488 TO *] (inclusive), properties.title:{A TO Z}(excluding A and Z)
Combinations: chocolate AND vanilla, chocolate OR vanilla, (chocolate OR vanilla) NOT "vanilla pudding"
Field search: properties.title:"The Title" AND text
Hello Clearml Community, I’M Having An Issue In Upgrading My Clearml Helm Chart From Version

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:

        - name: init-apiserver
          image: "{{ include "registryNamePrefix" (dict "globalValues" .Values.global "imageRegistryValue" .Values.apiserver.image.registry) }}{{ .Values.apiserver.image.repository }}:{{ .Values.apiserver.image.tag }}"
            - /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 }}
{{- 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?

Posted 7 months ago
Votes Newest

Answers 2

@<1523701827080556544:profile|JuicyFox94> thanks for the reply, I’ll create a github issue 🙂 !

Posted 7 months ago

Hi @<1523701717097517056:profile|ScantMoth28> , disabling atm we are not supporting Istio but I’m more than willing to look at a proposal like yours. Let’s discuss this on a new issue on github pls so we can keep track of it and find a good way to implement. thanks

Posted 7 months ago
2 Answers
7 months ago
7 months ago