<@ULVA73B9P> my deployment is not using one more p...
# ask-marvin
v
@Marvin my deployment is not using one more pool available and I am unable to unset default pool from deployment.
m
thought for 374.6 seconds
Thanks for flagging this. A couple of key points that should help: - In Prefect 3.x, every deployment must target exactly one work pool. There isn’t an “unset”/no-pool state. If you don’t want it to use the current pool, switch it to a different pool. - If your deployment still runs on the “default” pool after you switch, it usually means the deployment wasn’t actually updated, or a work queue/worker mismatch is preventing pickup. Recommended steps 1) Confirm what the deployment is actually using - Run:
Copy code
prefect deployment inspect "your-flow-name/your-deployment-name"
- Check the
work_pool_name
(and
work_queue_name
if present). This tells you what Prefect currently has saved for the deployment. 2) Switch the deployment to a different work pool Pick one of these approaches: - UI: - Open the deployment → Edit/Settings → Change the Work pool to your desired pool (and adjust/remove the Work queue if it references a queue from the old pool) → Save. - Python (recommended in 3.x):
Copy code
from prefect import flow

# If your flow code is local:
# from your_module import your_flow

# If your flow is in a repo, use from_source
flow.from_source("<https://github.com/org/repo>").deploy(
    name="your-deployment-name",
    work_pool_name="your-new-pool",
    # optionally clear or set a queue that exists in the new pool
    work_queue_name=None,
)
- API (advanced):
Copy code
import anyio
from prefect.client.orchestration import get_client
from prefect.client.schemas.actions import DeploymentUpdate

async def switch_pool(deployment_id: str, new_pool: str):
    async with get_client() as client:
        await client.update_deployment(
            deployment_id=deployment_id,
            deployment=DeploymentUpdate(work_pool_name=new_pool, work_queue_name=None),
        )

anyio.run(switch_pool, "YOUR-DEPLOYMENT-UUID", "your-new-pool")
3) Make sure something can pick up runs from the new pool - If you switched to a user-managed pool (e.g., Process, Docker, Kubernetes), ensure a worker is running against that pool. Without a running worker, runs will remain scheduled and appear “ignored”. - If you set a work queue name, it must exist under the new pool (or leave it blank to use the pool’s default queue). Why you can’t “unset” the pool - By design, the work pool defines where and how your deployment runs. A deployment cannot be saved without a pool in 3.x. Helpful docs - Work pools overview and management: Manage work pools - Managed execution (context on pools and infra): Managed infrastructure overview If you’re still stuck, could you share: - How you tried to change/unset the pool (UI, Python, or CLI)? - The output of:
Copy code
prefect deployment inspect "your-flow/your-deployment"
- The names/types of the pools you want to switch from/to, and whether a worker is running for the new pool. I’ll help you pinpoint why the deployment isn’t switching or being picked up.