few Questions about Prefect 2.0 [Orion]. 1. Why is there no Helm chart for Prefect 2.0 Orion 2. How many components are then in Prefect 2.0. Orion 3. Where can I find the components and Architecture of Prefect 2.0 Orion

Because it’s meant to be lightweight and just run on one machine. This page lists out the services

Just run on one machine, you mean “also run on just one machine” and not rather “only run on one machine”, if that is the case, is the scaling out possible with Orion ? if yes, how does kubernetes deployment scale out @Kevin Kho

A Helm chart will be released soon. You can scale out, yes. The API can be run on as many machines as you like, as long as a single database is being used.

Perfect, Thank you for the response Michael

Binoy, all great questions! 1. Helm support is on the roadmap - you can track the progress here https://github.com/PrefectHQ/prefect/issues/5562 2. There is a Postgres or SQLite DB used as a backend + Orion uvicorn-based webserver used to communicate requests between clients and REST API services used for orchestration + UI 3. Not documented yet, let me start with a Discourse topic

Thank you Anna, My question about HA was in terms of any Job locking if I deploy multiple Orion Instance, is there any Job/Deployment reservation happening, if not how is it stopping from multiple deployments happening from multiple instances of Orion at the same time

you can have as many Orion servers as you wish, in fact, if you install Prefect you can switch between various profiles - this allows you to e.g. have 2 different Orion instances, one for dev and one for prod and to switch between those you just do:

prefect profile use dev # or prod or any other profile

Binoy are you talking about scheduling of runs?

when it comes to limits of flow runs from specific deployments, check concurrency limits

That makes sense Anna, I was wondering about multiple instance running in Kubernetes for Prod itself, Can I run prod instances in “HA” mode

let me write a Discourse topic and send it to you, give me 5 min

yes scheduling runs such that 2 Orion Prod instances do not pick up the same job run

There’s locking on both scheduling of runs (with idempotency keys) and submission of runs to infastructure (with database/state locks)

awesome. Thanks

Yep!

May be its just my thing, but “_*Prefect 2.0*_ _*If you want to limit the number of flow runs executing simultaneously, you can leverage concurrency limits.*_” When I had read this statement, I was thinking that concurrency controls that only one Job at a given time.. But I am guessing it meant, it will control how many instances of same Job flow can be executed simultaneously

it's actually valid for both