Hey there 👋 If I have the

step_key

, how can I retrieve the

run_id

? I prefer a sql-query that I can execute on the postgres db. The context is that I’m doing an analysis on how much resources the job pods use in k8s. My starting point is the pod name, which gives me the run_id or step_key. I need to programatically retrieve the job and repo name with this information. It’s a one-time thing, so that’s why query-ing the postgres db directly seems the best/easiest way. Note that I cannot check/enter the pods because they might not live anymore.

the pod names are made using a hash https://github.com/dagster-io/dagster/blob/master/python_modules/libraries/dagster-k8s/dagster_k8s/job.py#L847-L863 so i think the only way to do that mapping from the data base is to search the serialized

event

column of the

event_logs

table for the events seen in the event stream by the k8s launcher / executor that include the metadata for what the job name was.

Thanks @alex. My approach is a bit problematic in that case. Do you have another suggestion on how to get the job or op name with the step_key or pod name as a starting point?

what exactly do you mean by

step_key

? In the dagster code base this maps directly to op/asset name with only pod name, the event log entries are the only piece of data that has persisted the mapping

Okay maybe I’m using the wrong names here. What I mean is, if

dagster-step-026fbeb46ca9a1014d7db5832b239aa4-9v5d4

the pod name, what I called the “step_key” is

026fbeb46ca9a1014d7db5832b239aa4

as per the code linked above, that “step_key” is really an md5 hash of

run_id

and

step_key

so can’t directly be used to calculate job / op name. There are other labels / attributes of the job and pod k8s entities that can be used to discern the job and op name, but if you truly only have pod name then the previously mentioned event log look up is the only place that has the information persisted by dagster.

Clear! Thanks a lot @alex