Hi ZippyAlligator65
You mean like env vars?

Yeah sort of, for example in the clearml-agent values.yaml there is a clearml.existingAgentk8sglueSecret param. But in the clearml-server helm chart, I am not seeing a way to like create this secret so that both the server container and agent conatiner could ultimately reference it as env variables. https://github.com/allegroai/clearml-helm-charts/blob/main/charts/clearml-agent/values.yaml#L19

Right now, Ive been helm deploying the server, generating a app cred pair in the ui, then pasting it into clearml.agentk8sglueKey: and agentk8sglueSecret: in the clearml-agent values.yaml, then helm deploying the k8glue agent. Which seems like there should be a more straightforward way to do this...

Yes you have to spin the server in order to generate the access/secret key...

Right exactly, but its just not clear how to accomplish that through the clearml-server values.yaml file. Is it possible to via the standard helm charts just by changing the values or do I have to make custom helm charts?

I think you are correct and the first time you spin the server it is not possible (I mean you need it up to get the access/secerey and only then you can insert them into the helm values) ... 😞

Ahhh yes upon re-reading your message I see what you were saying... Bummer... that seems like a bit of an oversight tbh. Any idea if you can (once of the server is up) generate credentials programmatically (not through the UI) in some way like maybe directly through the api server?

Bummer... that seems like a bit of an oversight tbh.

There is never a solution for those, unless the helm chart "knows" something about the server before spinning it the first time, which basically means a predefined access-key, I do not think we want that 😉

Hmm but doesnt a lot of the helm chart already work like that (like here for example https://github.com/allegroai/clearml-helm-charts/blob/main/charts/clearml/templates/secrets.yaml )? So like just imagine adding some optional additional secrets chart(s) like the one above that are randomly generated at deployment time (unless the user wants to hard code them into values.yaml) only their purpose would be to create the creds for the agent, then the agent just refences them by name via existingAgentk8sglueSecret: which already exists in the chart and boom shouldnt that work?

So essentially, the server helm chart creates randomly generated secret pair and deploys it as a shared k8 secret that pods can access. The server pod and the agent pod can now both access the secrets as environment variables .

So essentially, the server helm chart creates randomly generated secret pair and deploys it as a shared k8 secret that pods can access.

This is the tricky part, for the helm chart to be able to create it, it means it can login to the server it means there is a secret embedded in the helm chart that lets you access the default server. you see my point ?

I see you concern but I dont think we are talking about the same thing... Maybe I am misunderstanding the server's capabilities, is there some method that when the server starts, credentials will be populated via environment variables? Like where the documentation refers to "fixed users" you can provide via config. Then the helm side, you use something like this: https://itnext.io/manage-auto-generated-secrets-in-your-helm-charts-5aee48ba6918 So essentially, the point of the actual string secret is generated is in the helm chart, it deployed as a shared k8 secret, both the server and agent access it via env variables.

Ballpark something like this as optional in the server charts... but I am new to Helm so maybe again I am missing something.

I have to admit, I'm not sure...
Let me talk to backend guys, in theory you are correct the "initial secret" can be injected via the helm env var, but I'm not sure how that would work in this specific case