After a pair programming session into the dagster helm chart

Question

After a pair programming session into the dagster helm charts with < Michel Rouly> we discovered that the `imagePullSecrets` for the `K8sRunLauncher` are controlled by the `dagster dagster` helm chart and not the corresponding `dagster dagster user deployments` helm chart It would be nice if the `dagster user deployments` helm chart could create and associate the secret with the `K8sRunLauncher`

rex · Answer

Are you deploying the subchart separately

Jordan W · Answer

We are

rex · Answer

hmm it s a bit of an antipattern for a Helm subchart to be aware that it is a dependency of another chart

rex · Answer

unless we had some self discovery mechanism like or it s difficult for the Dagster infrastructure here specifically the run launcher to know what new image secrets it needs to pick up

rex · Answer

what if you manage the serviceaccount for `dagster` You could include the image pull secrets there

rex · Answer

the serviceaccount for `dagster user deployments` could use the one created above in this serviceaccount you can configure all the image pull secrets that you need

rex · Answer

it s a little non ideal though since now each deployment in `dagster user deployments` could potentially have more secrets than it needs to deploy the pods for its image

Jordan W · Answer

What we did was have the parent `dagster dagster` and child `dagster dagster user deployments` charts use the same imagePullSecret and have the parent chart create and manage the image pull secret What would be nice is to allow the `dagster user deployments` to control its corresponding `RunLauncher` as the kubernetes configuration can be different Being the `imagePullSecret` or environmental variables