adding @<1523701087100473344:profile|SuccessfulKoala55> to the conversation because I’m not totally sure the problem relies on ingress, it looks to be a bad token but it shouldn’t since init was good

it should be ok, for dependency charts (mongodb/elastic/redis) you need to check values by the owner (link is in valus.yaml sections)

not sure if provisioner did something unexpected

really weird, can you try to totally remove any cookie domain related?

btw I think it's related clearml-task usage; did you try to create a pipeline with decorators creating it with clearml-task before?

Hi Martin 😄 ok got it but now the question: how I can pass this to the train-agent deployed with Helm chart?

it’s usually needed for autoscaler to decide when and how to scale up and down

s o kubectl -n clearml get ingress

so you are using docker-compose?

@<1673863788857659392:profile|HomelyRabbit25> I see your comment on that PR, if no further feedback will be there, I will try to eventually improve that PR by myself when possible.

so do you want to mount files into agent pod?

this is interesting

moreover url exposed by nginx should be under https

I’m just trying to understand of it’s something related ceph or clearml deployment

good it’s solved 😄

It should work I think :)

I wouldn’t say it’s related RBAC because the issue seems Networking realted so connection timed out

` apiserver:
additionalConfigs:
services.conf: |
auth {
# Fixed users login credentials
# No other user will be able to login
fixed_users {
enabled: true
pass_hashed: false
users: [
{
username: "jane"
password: "12345678"
name: "Jane Doe"
},
{
username: "john"
password: "12345678"...

first I noticed a mistake I did when suggesting config, this:

can you post output of
kubectl get po -A -n clearmlpls?

btw as general rule, it’s always safer to take a data backup before a chart upgrade regardless of version level

internal migrations are directly done by apiserver on startup

I’m just going to include these credentials in pod template too

Yes, one interesting info would be: what dynamic storage provisioner are you using? (storageclass)

h i, if I’m not wrong, mongodb doesn’t have an ARM image (and you are using a Silicon one like me ofc 😄 )

you can try use a specific image like docker.io/arm64v8/mongo:latest

if you have problems with other images I suggest to run docker in emulation mode so you can run amd64 images

not official but should work

If you have ALB you will just need to add some annotations on ingress rules depending on your setup. btw for now , since you already have everything in place, I suggest to just add values to /etc/hosts and see if it works

Hey ApprehensiveSeahorse83 , I didn’t forget about you, it’s just a busy time for me; will answer during the day after a couple of more tests on my testing env.