Hi folks, I am trying to mount some volumes to dagster job. For instance,

download_host_fe_job_stg = download.to_job(
    name='download_firebase_fe',
    config=partitioned_config,
    tags={"dagster-k8s/config": {
        'job_config': {
            "volumes": [
                {"name": "volume1", "secret": {"secret_name": "dagster-gcp-secret"}},
            ],
            "volume_mounts": [
                {"name": "volume1", "mountPath": "/tmp"},
            ]}
    }}
)

But i got incorrect

TypeError: __init__() got an unexpected keyword argument ‘volumes’

I was wondering if you can help me out? Actually, I follow code snipset in

construct_dagster_k8s_job

I think you want something like this:

"dagster-k8s/config": {
            "container_config": {
                "volume_mounts": [
                    {"name": "volume1", "mountPath": "/tmp"},
                ],
            },
            "pod_spec_config": {
                "volumes": [{"name": "volume1", "secret": {"secretName": "dagster-gcp-secret"}},],
            },

(note secret_name changed to secretName). We're going to improve the docs and examples around this in the release next Thursday, and allow snake case keys (secret_name) in addition to camel case keys (secretName).

One thing that still confuses me to this day regarding dagster-k8s:

dagster-k8s/config

is used to add certain specifications to a dagster Job / Op but, depending on which executor you are using, those tags might be ignored. Tags for Jobs are always picked up, but tags for ops will be used only if the job executor is the

k8s_job_executor

otherwise they will be ignored silently. Am I missing something here?

That's correct - only executors that launch each op in its own pod are able to use the tags when they're applied to an op

Would we maybe print an error rather than failing silently? Do you think it's possible? Also, it is possible to change the default executor?

By failing silently, you mean ignoring the config on the tags? That's tricky because it would require us to put k8s-specific logic in the core executor code. But generally we don't love this tag solution and are investigating other ways to solve this problem

Yeah that's what I meant... I would be curious to know what are your thoughts about tags and how are you planning to replace them

I don't think there are any concrete ideas yet that are fully-formed enough to share yet, but it would be nice to convey the execution intent in a more structured / typed way than nested JSON

thanks guys