I am searching for something like the dagster_cloud.yaml approach: https://docs.dagster.io/dagster-cloud/deployment/agents/kubernetes/configuration-reference#per-location-configuration bot for OSS.

Hey Grigorii - it's not exactly the same, but configuration on the user deployments in the helm chart is kind of like that, in that configuration that you set there will be passed through to the runs as well: https://docs.dagster.io/deployment/guides/kubernetes/deploying-with-helm#step-6-configure-your-user-deployment

@daniel, thank you for the answer! I have noticed this but I am not using helm charts, I'm writing plain kube configs. Can you tell me please how is this configuration applied for the runs actually?

It sets a "DAGSTER_CONTAINER_CONTEXT" environment variable on the user code deployment: https://github.com/dagster-io/dagster/blob/master/helm/dagster/charts/dagster-user-deployments/templates/deployment-user.yaml#L58-L60

Wow! So I can fit all my configuration into the

DAGSTER_CONTAINER_CONTEXT

env variable on the grpc server pod and this configuration will be applied for the runs with the grpc server code?

that's right

I will try that ASAP, thank you very very much!

i'm not aware of anything else that uses it - we have tests in place that verify that it works

For whoever will run into the same issues as me, the

DAGSTER_CLI_API_GRPC_CONTAINER_CONTEXT

env variable actually overrides the run_launcher (K8sRunLauncher) configuration that you specify in

dagster.yaml

. If you remove the run_launcher (K8sRunLauncher) configuration from the

dagster.yaml

, you will end up having DefaultLauncher for the code locations and the

DAGSTER_CLI_API_GRPC_CONTAINER_CONTEXT

variable with the k8s configs ignored.

yeah to clarify, this is additional configuration for a particular code location, it's not intended to replace the run launcher config