https://prefect.io logo
Join Slack
Powered by
Hey there again everyone! Hopefully a quick questi...
# prefect-server
c
Hey there again everyone! Hopefully a quick question about doing a 
create_flow_run.run(flow_name="flow-2")
within a task created by a 
KubernetesRun
... assuming i have
Copy code
with Flow("flow-1", run_config=KubernetesRun(...)):
  ... creates task that does a create_flow_run.run(flow_name="flow-2") ...
should 
flow-2
receive/inherit the 
run_config
from 
flow-1
?
k
There is no RunConfig inheritance. It has to be defined on the subflow, but I think you can explicitly pass a new RunConfig as well if you want. It’s more common though to pass parameters down to link the parent and child
create_flow_run
can take in a RunConfig here
c
thanks @Kevin Kho then thats what i experienced and wanted to make sure i wasn't crazy or doing something wrong! also: your response time for questions here is on point! ⭐⭐⭐⭐⭐
upvote 1
👍 1
k
Thank you!
w
@Kevin Kho in this case, “flow-2” would also have been defined, registered, and serialized with a KubernetesConfig. i think @Christian Nuss was seeing that it wasn’t working though? i.e. the labels defined in the flow being called from the first KubernetesRun weren’t set
i worded that awkwardly. let me rephrase
I believe he was seeing that the registered flow, which was being called by the first flow, which was instantiated as a KubernetesRun, wasn’t getting its run_config labels set on it when it was instantiated, even though it’s defined in the flow itself. Is that right @Christian Nuss?
still awkward, but hopefully less so…
c
right correct as @William Grim said, we have a 
with Flow("flow-2", run_config=KubernetesRun(...)):
registered
k
Ah ok so you have a subflow registered with KubernetesRun but it doesn’t seem respected? What do you see when you go to the Flow page in the UI? There should be a space for RunConfig and labels?
c
1 sec, standby...
😂 1
strange its adding a nonsense label
so its not getting scheduled
k
Ah ok before you register, you can do:
Copy code
flow.storage.add_default_labels = False
and then try re-registering.
Wait so you have pending runs but the create_flow_run is working right?
c
create_flow_run does appear to be working, as the new sub-flow gets registered and the run config looks correct! so just a labeling issue
k
Gotcha yeah just remove the default label and I think this should be good. What storage are you using though? Normally the default label is attached to local storage
c
i made some hackery in this case with volume mounts for Local Development purposes
k
Ohhh yes ok that sounds good and you can turn off the default label that is part of Local storage
c
🚀
worked like a charm, thx!
👍 3
in Production we will use S3 Storage + Kube, do you think i should add the 
add_default_labels=False
there too? (feels like i should for consistency)
w
@Christian Nuss i believe the “nonsense label” is your instance’s “hostname”
upvote 1
a
no need for add_default_labels when using S3 storage - it's only applied when using local storage and William is correct, this cac0475... is the hostname of your machine 🙂
3 Views
Open in Slack
PreviousNext
Powered by