The cloud-native orchestrator for the whole development lifecycle, with integrated lineage and observability.

dagster

After a pair programming session into the :dagster: helm charts with <@U022KG8SGV6>, 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`.

Are you deploying the subchart separately?

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

unless we had some self discovery mechanism like <https://github.com/dagster-io/dagster/issues/6295> or <https://github.com/dagster-io/dagster/issues/4411>, it’s difficult for the Dagster infrastructure (here, specifically the run launcher) to know what new image secrets it needs to pick up

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

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

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

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