*New experimental `submit_as_runner` feature in 2....
# ask-community
d
New experimental
submit_as_runner
feature in 2.4.17
I was super happy to see this feature make it into the latest release but am trying to figure out how to make it work for a simple use case. https://github.com/PrefectHQ/prefect/releases/tag/2.14.17 I have a simple list of files I want to submit to a subflow (which must process sycronously, not async) and want to have the web server parallel run those to so some scientific processing. Based on the example in releaase notes (which were, um... complex for this simpel case), I am figuring I should be able to do the following:
Copy code
@flow(log_prints=True)
def ingest():
    path = "/data/staging/obj"
    files = file_checker(path)   # file_checker is a task
    submit_to_runner(
        sci_processing, [{"file": file} for file in files]
    )
    wait_for_submitted_runs()
And see the runners spin up multiple runs of the sci_processing.through the subflow
sci_processing
. (I'm having a bit of trouble with spinning up the webserver runners at the mo, cause I'm not sure
prefect config set ...
is working as advertised, but before going down this bunny hole, does anyone see a problem with the above as an approach?
n
hi @Daryl - have you set the following settings?
Copy code
PREFECT_EXPERIMENTAL_ENABLE_EXTRA_RUNNER_ENDPOINTS=true
PREFECT_RUNNER_SERVER_ENABLE=true
what issues are you encountering? your example makes sense to me as shown above
d
Hey @Nate I do have those set or at least set them via the
prefect config set
command. I'm getting a
ERROR:    [Errno 99] error while attempting to bind on address ('::1', 8080, 0, 0): cannot assign requested address
when spinning it up on docker compose with two docker containers (server and cli) from
PrefectHQ/prefect
even with the ports 8080 exposed in the docker compose ports directive. Any ideas as to what may be wrong here? (do I need a separate docker container in the compose for the Runner?)
👍 1
n
hmmm - would you be able to share the whole stack trace? i can investigate more when im at my computer
and you should not need more than one container for the runner (in general, you may have a setup where that would make sense) - your serve process should spin up the web server on localhost:8080 as long as you’ve got that server_enabled=true setting
d
Hey @Nate I definitely think this has something to do with my docker setup. As I mentioned I use a docker compose to pull the 2.14.17 docker and then spin up a prefect-server and a prefect cli instance with a common network between them. When I
docker exec
and shell into the cli version - this is how I usually submit my flows, I get the
ERROR:    [Errno 99] error while attempting to bind on address ('::1', 8080, 0, 0): cannot assign requested address
which happends when I run the
python -i atlas_ingest.py
, it deploys (when I get the error, but normally I'd do this and then run the
atlas_ingest()
function. I've checked in the docker compose and I do have port 8080 open on the docker server, so imagine it's some other issue here though a bit stumped. The docker-compose.yml is below for reference.
Copy code
version: "3.9"
services:
  ### Prefect Server API and UI
  server:
    image: prefecthq/prefect:2.14.17-python3.11
    restart: always
    volumes:
      - prefect:/root/.prefect
      - ./data/staging:/data/staging
      # - /data/staging:/data/staging
    entrypoint: ["/opt/prefect/entrypoint.sh", "prefect", "server", "start"]
    environment:
      - PREFECT_UI_URL=<http://127.0.0.1:4200/api>
      - PREFECT_API_URL=<http://127.0.0.1:4200/api>
      # If you want to access Prefect Server UI from anywhere other than the Docker host machine, you will need to change
      # PREFECT_UI_URL and PREFECT_API_URL to match the external hostname/IP of the host machine. For example:
      #- PREFECT_UI_URL=<http://external-ip:4200/api>
      #- PREFECT_API_URL=<http://external-ip:4200/api>
      - PREFECT_SERVER_API_HOST=0.0.0.0
      # - PREFECT_API_DATABASE_CONNECTION_URL=<postgresql+asyncpg://postgres:postgres@database:5432/prefect>
      - PREFECT_API_DATABASE_CONNECTION_URL=sqlite+aiosqlite:////root/.prefect/prefect.db
      # Uncomment the following line if you want to use the 'S3 Bucket' storage block instead of the older 'S3' storage
      - EXTRA_PIP_PACKAGES=astropy prefect-sqlalchemy psycopg2-binary datetime httpx
    ports:
      - 4200:4200
      - 8080:8080

  ### Prefect CLI
  cli:
    image: prefecthq/prefect:2.14.17-python3.11
    working_dir: /root/flows
    volumes:
      - ./flows:/root/flows
      - ./data/staging:/data/staging
      # - /data/staging:/data/staging
    environment:
      - PREFECT_API_URL=<http://server:4200/api>
      #       Use PREFECT_API_KEY to use the CLI to interact with Prefect Cloud
      #     - PREFECT_API_KEY=YOUR_API_KEY
      - EXTRA_PIP_PACKAGES=astropy prefect-sqlalchemy psycopg2-binary datetime httpx
    # profiles: ["cli"]
    command: tail -f /dev/null

volumes:
  prefect:
  db:
  # minio:
networks:
  default:
    name: prefect-network
n
hi @Daryl - would you be able to try installing
main
and seeing if that fixes your problem? we may have introduced a slight bug in the default settings around this that we reverted yesterday but have not yet released
d
@Nate Is that a 2.14.18 docker or 2.14.17.1 docker image for it? I've been leaning heavily on docker compose for these these things to containerize the whole shebang.
(and btw, the way, thanks for the help. A bug would make me feel betetr actually, since I was banging my head against this for a while since things worked fine under 2.14.12 and was thinking it was probably me... 🙂
(it still might be... 😛 )
n
I see - let me get back to you on this. im still actively working through this 🙂
d
No worries. I am willing to kick the tires on a docker image as soon as you have one. I really need the parallel processing on this one (since we have a big beefy server and the only way we can process in time is in parallel.). Lemme know if there is anything else I might be able to do t help diagnose the issue.
(if there's a way to override/install the main for an existing image - i somehow think not since neither docker nor pip, could totally do that if it'll help out.).
@Nate I noticed 2.14.18 dropped about 8 hours ago (while us here in APAC were asleep.) and it mentions webserver settings. Will try it out and see if it fixes my particular issue. 🙂
n
hey @Daryl - I just tested out 2.14.18 on server and its working for me with defaults - we did have a slight error based on the runner's default port that should be fixed now ill give you my example as a starting place if its helpful, feel free to reach out with any questions / troubles
d
Hey @Nate I'm using the 2.14.18 docker and have set the
prefect config set PREFECT_EXPERIMENTAL_ENABLE_EXTRA_RUNNER_ENDPOINTS=True
and the
prefect config set PREFECT_RUNNER_SERVER_ENABLE=True
I can see them set that way in my settings. I've also set the docker ports for the wwebserver container to expose 8080:8080. However, when I run my deployment< i am getting the following error on the run:
Copy code
File "/usr/local/lib/python3.11/concurrent/futures/_base.py", line 401, in __get_result
    raise self._exception
  File "/usr/local/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 355, in _run_async
    result = await coro
             ^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/prefect/runner/submit.py", line 135, in submit_to_runner
    raise ValueError(
ValueError: The `submit_to_runner` utility requires the `Runner` webserver to be running and built with extra endpoints enabl
ed. To enable this, set the `PREFECT_EXPERIMENTAL_ENABLE_EXTRA_RUNNER_ENDPOINTS` setting to `True`.
03:34:38.685 | ERROR   | Flow run 'practical-cockatoo' - Finished in state Failed('Flow run encountered an exception. ValueEr
ror: The `submit_to_runner` utility requires the `Runner` webserver to be running and built with extra endpoints enabled. To 
enable this, set the `PREFECT_EXPERIMENTAL_ENABLE_EXTRA_RUNNER_ENDPOINTS` setting to `True`.')
03:34:39.037 | INFO    | prefect.flow_runs.runner - Process for flow run 'practical-cockatoo' exited cleanly.
For whatever reason, even with the cofigs set, it still seems to not believe that runner is set (to be sure, I set it on both the server and the cli container.
n
are you spinning up containers for each flow run that wouldnt have the settings configured?
d
Nope. These are static containers as per the docker config I showed you. I
docker compose up -d
to get both to stand up, then
doccker exec
into the shell of the cli container and run the python file. II also just switched over the serve satement to be precisely like yours which still throws the ERR so for some reason Runner is either blocked in starting or not starting at all.
You can spin up the docker compose I gave you and duplicate the issue I imagine. In the python file I have (atlas_ingest.py) the two relevant pieces would be
Copy code
@flow(log_prints=True)
def atlas_ingest():
    atlas_path = "/data/staging/atlas/obj"
    files = file_checker(atlas_path)
    submit_to_runner(
        sci_backend_processing, [{"file": file} for file in files]
    )
    wait_for_submitted_runs()
and this handy bit Icopied from your test file:
Copy code
if __name__ == "__main__":
    serve(atlas_ingest.to_deployment(__file__), limit=10, webserver=True)
(it may be something stupid I've done, but I don't think so. I would expect this to work based on the fact it's been working in serial fine.... ).
n
hm - the fact its complaining about the settings not being configured is weird to me i can try and replicate your docker setup and see if i can figure out what's going on
d
The starnge tihng is when I look at the Settings on the server in the web interface the settings are correct for the Server. (I also for good measure set them in the cli but wonder if it somehow thinks the cli is involved somewhere and since no server is running there...
(but as I said, this works fine for submitting jobs and deployments having them run in serial (without WebRunner, so would be curious if that were the case).
@Nate Just to double check I also ran your test program and also get the same errors, so maybe a server or docker issue, not sure... Hmmm...
n
hmm i will look more into this tomorrow after I have a chance to put together something like your setup myself
d
@Nate Cool. Super curious to see what you find out. Btw, I'm somewhat new to Prefect, so if my setup in docker for it is questionable, please call it out. Like I said, it worked for running things from the cli and ran fine in serial, but it's possible I've got a weird directive or something in there, but like I said, it seems like it should all work. Kinda curious as to what the problem may be.
Excited to crush the bug/prob though and get my stuff running in Prod in Prefect though... I really love how much of a nicer dev experience it is than Airflow. Big fan already. 🙂
n
hey @Daryl - i've got something hacked together for you thats similar to your example & working for me https://github.com/zzstoatzz/submit-to-runner-demo let me know if this is helpful, i didn't spend a ton of time here but happy to revisit if something's still going weird for you
d
@Nate Awesome! Lemme check it... Might need to get through work today here in Hong Kong though before looking. Thank you!!
Hehe... took a quick boo at the code: 2.14.20... 🙂
Will def try this this evneing. Woo! \0/ Thanks!
Heya @Nate! Alright, I spun up your
docker compose
. I managed to run the simulated work tasks from the deployment (so, yey!!!), but on the
docker compose up
I got the following errors. However, running the flow from the deployment UI interface worked fine. I'm going to try to adapt what you did to my ingest pipeline and see what happens. Will update you later, but just thought you'd want to know about the solid progress. Def looks like the simulated work is runing in parallel Error log from the cli spin up of docker compose after it pulled 2.14.20. Pretty sure it was related to your flow code though as it went away when Itried using my code.
@Nate Just wanted to let you know that after some serious after-dinner hacking on this, I've got the concurrent runs going!! (yes, double exclamation mark... =] ). So, beside the 2.14.20, I'm guessing the issue was needing that server container to run the WebRunner? In any case, got the initial test case running last night for the ingest pipelines after you help, so just waned to say thank you sooooo much. Still got to puzzle out why my ephemerides calls are sometimes failing an then causing database insert issues at the end, but that is just bookkepping. Once again, thanks so much for this. I intend to write a proper blog post up about this shortly, so other people can find the solution. Thanks!!
n
catjam
woo! so glad you’ve made progress 💙 a blog post would be awesome, make sure you let me know when you write it - i’m sure we’d love to amplify it cc @Sarah Krasnik
d
Will def do so. It is next on the list right after I puzzle out the last issues in the pipeline and move ingestion over... 🙂
s
Thanks for your patience @Daryl, and do feel free to ping me directly with a blog link! If you're interested in having it on the Prefect blog, I'm happy to also work with you on that.