I've run into an interesting edge case with the user deployment Helm chart. Seems like, if you separately deploy the

dagster/dagster

and

dagster/dagster-user-deployments

helm charts, there's no way to set environment variables on pipeline runs from the

dagster-user-deployments

release. You can only influence them via

pipelineRun

in the

dagster

deployment. Which strikes me as odd. What if independent

dagster-user-deployments

require independent environment variable settings?

@geri also ran into this - here is a work around that I suggested, and we can consider adding this as first class support:

1/ the run launcher loads the environment variables from a configmap. currently, this configmap is from created from 

.Values.pipelineRun

2/ Instead, we can have each user-code-deployment have a configmap of environment vars (or maybe just one configmap for all the user-code-deployments).

3/ You can specify the name for the configmap, and then add the name of this configmap to the celery run config so that it knows it load from this configmap (rather than the one created by 

.Values.pipelineRun

)

4/ so now you can update the environment variables in the 

dagster-user-deployments

 chart, rather than updating 

.Values.pipelineRun

That should decouple the dependency of 

pipelineRun

 , so that we can finally remove it

I was just about to ask that!

it’s specified in the executor run config, which you can provide as

env_config_maps

which you can provide as

env_config_maps

wait, what? I didn't know that. the examples on that page are all either YAML via dagit/CLI or in python.

yeah we’re misunderstanding each other a bit. I think you’re overloading the term “tag” a bit - tags are just metadata on the pipeline run, while run configuration allows you to provide parameters into the pipeline before execution

ahh. I'm assuming this is the

celery_executor

you're saying accepts

env_config_maps

in its run config?

yep!

ok, that's why I was misunderstanding. we've just been using the

multiprocess_executor

so far, so I hadn't seen that config key.

Ah i see -

.pipelineRun

was mostly an artifact for configuring the celery executor

makes sense. even without the celery executor, though, it's a convenient way of passing a

configmap

to a pipeline pod.