Hey all I'm on an older version of dagster `0.11.1...
# deployment-kubernetes
k
Hey all I'm on an older version of dagster
0.11.13
and attempting to get k8s pod affinity working at the solid level. I'm currently using something like:
Copy code
tags = {
    "dagster-k8s/config": {
        "pod_spec_config": {
            "affinity": {
                "nodeAffinity": {
                    "requiredDuringSchedulingIgnoredDuringExecution": {
                        "nodeSelectorTerms": [
                            {
                                "matchExpressions": [
                                    {
                                        "key": "lifecycle",
                                        "operator": "In",
                                        "values": ["spot"],
                                    }
                                ]
                            }
                        ]
                    }
                }
            }
        }
    }
}
and it's still attaching to some ON_DEMAND nodes that I have set up. Any idea why? Or is this potentially a known bug this older version? I'm using the K8sJobExecutor as well, not sure if that could be problematic too
I've verified that the label in question is present on the spot nodes as well,
lifecycle=spot
j
Could you verify that the affinity is showing up in the K8s Job spec?
k
I see nothing in the jobs for the job or run
Am I missing some sort of configuration that lets dagster utilize the solid config?
j
I see nothing in the jobs for the job or run
Just to confirm, you’re looking at the Job created for the solid that you’ve tagged?
k
Correct, I just verified by running
describe job
and saw nothing related to affinity. Is there some other place I should validate?
j
Ah I believe this was a bug with the
k8s_job_executor
in 0.11.13
k
👍 Any idea what version resolved it? We're finally getting back on the update track here.
j
Looks like it was resolved in 0.12.0
While on
0.11.13
, it looks like if you set that tag on the pipeline, it will be applied to all solids and then run worker. Which is probably not quite what you want
k
Perfect, thanks! We'll be updating to that soon.
j
back on the update track
The executor has been getting more stable, but there have been some recent bugfixes even up to 0.13.13. There’s no migration required from 0.12 to 0.13, so you could consider the jump
k
I've been pleased with the executor so far even on this version. Are the naming changes for solids / pipelines not enforced in 0.13? We haven't updated to ops/jobs yet
j
It’s fully backwards compatible, there will just be a legacy icon on them in dagit
💯 1
k
Awesome! Then I will definitely be making moves to that ASAP. Any recommendations on update path? I was going to do 0.11.13 -> 0.11.16 -> 0.12.0 -> 0.12.X -> 0.13.0. But it sounds like if there's no migration I can just do 0.12.0 -> 0.13.0?
j
You may actually be able to just go to the latest 0.13 and run the migration from there. cc @daniel, is a stop on 0.12 needed?
d
yeah, a single upgrade from 0.11 to 0.13 should be fine
👍 1
k
Wow that's awesome! Thanks a bunch guys, I'll get on that
d
always a good idea to backup just in case, but the schema migration should be able to start at 0.11 and end on 0.13
j
Also note the upgrade doesn’t need to be to 0.13.0, any dot version should be fine
👍 1