# Point to the internal API server hostname APISERVER= `

Path to ServiceAccount token

SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount

Read this Pod's namespace

NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)

Read the ServiceAccount bearer token

TOKEN=$(cat ${SERVICEACCOUNT}/token)

Reference the internal certificate authority (CA)

CACERT=${SERVICEACCOUNT}/ca.crt

Explore the API with TOKEN

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${A...

I guess yes but honestly I’m not sure you will get the right results

probably
is not accessible from your pod

if it turns 503 it’s not network but something on top of it

https://github.com/allegroai/clearml-helm-charts/blob/9c15a8a348898aed5504420778d0e815b41642e5/charts/clearml/values.yaml#L86

I’m guessing if I can set it trough Helm chart by default, will investigate by the end of the week, ty ScrawnyLion96 to point me on this interesting behavior!

Hi Ofir, ty for feedback

from https://kubernetes.io/docs/tasks/run-application/access-api-from-pod/

additionaConfigs is a section under apiserver

I don’t think you need to pass these env vars in extraenvs, references are automatically generated by chart. After removing them, pls post webserver pod logs here and let’s see if we can spot the issue, ty.

if mounts are already there everywhere you can also mount directly on the nodes on a specific folder then use rancher local path provisioner

btw a good practice is to keep infrastructural stuff decoupled from applications. What about using https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner ? After applying that chart you can simply use the generated storage class; wdyt?

other wise yes, if this is not an option, you can also mount what is already existing so pls open an issue in new repo helm chart and we can find a solution

Hi BurlySeagull48 , I’m interested in your use case and I think we can find a solution. NFS mounts have the same path in every node?

if you already have data over there you may import it

I think we can find a solution pretty quickly after some checks. Can you pls open an issue on new helm chart repo so I can take care of it in some day?

Or do you want to dinamically mount directly an nfs endpoint? (I understood you need this one)

ok, will try to find a solution then, ty

Just to be sure

O k, I’d like to test it more with you; credentials exposed in chart values are system ones and it’s better to not change them; let’s forget about them for now. If you create a new accesskey/secretkey pair in ui, you should use these ones in your agents and they shuld not get overwritten in any way; can you confirm it works without touching credentials section?

y ou can siply generate in UI the keys

Hi BeefyHippopotamus73 , on EKS it’s preferrable to use ALB but you can also work with your nginx. You need DNS records with hostnames you setup pointing to that External IP. If you just need to test, you can simply add entries in you client machine /etc/hosts file (if you are on *nix)

yay, ty

Ty, I have other stuff that I'd like to send but it's better to get these eventually merged first so I can proceed to shiny news PR in the near future 😄

great ty!

so you installed chart version 3.10.1

yes

but I’m going to patch this soon so it will take the default storageclass automatically

now I’m leaving for today but let me know if it works. Have an nice day!

I absolutely need to improve the persistence part of this chart 😄