. This includes some secrets and some URLs and object ids on some internal rest services. Before we used the prefect server, we had a small cli that would populate the
and use it when running the flow:
My ultimate objective is to have a flow with a default context that I can run from the UI or schedule it with that context when deploying it. In my question of April 19th, @Jeremiah pointed out that there is no way to set these contexts at the moment and you will discuss it internally later… is there any update on this front? Otherwise, I am looking for alternatives or workarounds: One workaround would be to understand where the context would be set on an agent, worker, or runner (I am not sure which one). Jeremiah also pointed our that the FlowRunner requests the context from the server, but I can’t find where or even if a flow has its context saved anywhere (there does not seem to be a field named context on the
with prefect.context(**our_custom_vars): flow_state = flow.run(parameters=flow_parameters, ...)
query). Another workaround would be to populate environment variables or change the default
of the agent, worker, or runner (I am not sure which one) so that the
is populated with these values. I am not sure if this would work. Another workaround may be to override the
method, so that the flow can retrieve the context when unpickled. I am not sure if this would work either. Any ideas on which of these workarounds may be the best bet here?
for the mapped function, but it only works for unmapped tasks
X does want to push back because docker is a involved, and has many unsolved aspects since the daemons run as root. It didn’t look like the prefect ui could run in singularity which is the user-space container management thing that they were talking about.
If it is possible to install the prefect ui as a non-docker, either as a library, or on a server. I think that has many fewer concerns from the systems team.