In my setup we have one code location that we want to be configurable based on a set of environment variables. With that, we deploy multiple versions of the same code location at the same time, however, with a different set of configurations. We want this behavior to isolate our projects. They all have the same assets and jobs, but it would be too much information to be displayed in Dagit if we had all of the projects partitions in one place. A potential solution to this problem is to have a nested partition mechanism, but this is beyond the scope of my question. Given that context, I'm having a hard time passing these environment variables from my code location to the pods in which the runs actually happen. It seems that the forwarding mechanism triggered when you define

env_vars

in the

run_launcher

config map expects the environment variables to be set in the daemon pod and not in the code location pod, which makes sense since the architecture assures there is only one daemon and I believe that's where the job running pods are spawned from. Anyway, I'm wondering if there is a way to solve my issue or if I'm going to have to model our use case differently 🤔

A few considerations: 1. You can disable that setting (the one that forwards config/env vars) and then explicitly set dagster/k8s tags to set env vars for the jobs. This doesn’t currently play nice with automaterialization and some ad-hoc asset materializations, but works great with all jobs, including asset jobs. We do this for security reasons - we have different secrets/service accounts for different jobs that grant access to different data warehouse users. 2. Just wanted to mention, you can run multiple code locations out of the same user code deployment. It’s a pattern I was using long before the current move to Definitions, but there is a path provided to use those still. This works particularly well when combined with #1

Thanks a lot for the reply! I'll certainly try the multiple code locations from the same deployment