<@ULVA73B9P> how to run a deployment from another ...
# ask-marvin
n
@Marvin how to run a deployment from another deployment and wait for that deployment to complete
m
To run a deployment from another deployment in Prefect 2.0, you would essentially have to create a flow that triggers another flow's deployment. This would involve having a flow that uses the Prefect API or CLI to start the execution of another flow's deployment and then checks the status of the executed flow run until it is complete. However, the information extracted from the documents did not provide a concrete example of how to do this. Typically, you would use the
create_flow_run
function from the
prefect.client
module to create a new flow run, and then use a method like
get_flow_run_info
to poll the status of the run until it's completed. Here is a conceptual example in python pseudocode:
Copy code
python
from prefect import flow
from prefect.client import create_flow_run, get_flow_run_info
from prefect.orion.schemas.states import Completed

@flow
def trigger_flow_and_wait(deployment_id):
    flow_run_id = create_flow_run(deployment_id=deployment_id)
    
    # Wait for the flow run to complete
    flow_run_info = get_flow_run_info(flow_run_id=flow_run_id)
    while not isinstance(flow_run_info.state, Completed):
        # Sleeping is often a bad practice; you'd want to implement some
        # delay with exponential backoff and perhaps a timeout to prevent
        # infinite loops.
        time.sleep(10)
        flow_run_info = get_flow_run_info(flow_run_id=flow_run_id)

    return flow_run_info.state

# Use the deployment ID of the flow you want to trigger
trigger_flow_and_wait(deployment_id="deployment-id-goes-here")
For a more accurate and detailed implementation, I would recommend reviewing the Prefect documentation or any updated examples provided by the Prefect 2.0 community, since the precise APIs and best practices can evolve.
n
@Marvin who creates Idempotency key by default when running a flow and running a deployment?
m
The excerpts from the documents I searched did not provide specific details about who creates the idempotency key in Prefect 2.0 or the mechanics behind its creation. In software systems, an idempotency key is often used to prevent the duplication of requests, such as when creating or running something like a deployment or a flow run. Typically, the client or the system initiating the request generates an idempotency key to uniquely identify the operation. In Prefect 2.0, an idempotency key could be generated by the Prefect API or client when you initiate a flow run or create a deployment to ensure that if the same request is sent multiple times, only one operation is performed. For precise information on how idempotency keys are used and handled in Prefect 2.0, we'd likely need to refer to more specific sections of the Prefect documentation or the source code, where the behavior of idempotency keys would be implemented and described in more detail. If this is something you need, I can search the documentation or codebase further for you.
n
@Marvin when a subflow fails in a parent flow and I retry the parent flow, the parent flow creates a new subflow instead of the existing subflow. how do I retry so that a new subflow is not created.
n
@Marvin
run_deployment
is a better answer
m
In Prefect 2.x,
run_deployment
is a function that you can use to create a flow run from a deployment in a Python script. Here's an example of how you can use `run_deployment`:
Copy code
python
from prefect.deployments import run_deployment

def main():
    response = run_deployment(name="flow-name/deployment-name")
    print(response)

if __name__ == "__main__":
    main()
Using this function, you can programmatically trigger a flow run for a specific deployment. It requires you to specify the combination of the flow name and the deployment name. Remember that, when using agents and work pools in remote environments, you also need to ensure the
PREFECT_API_URL
environment variable is set to enable the agent to communicate with Prefect Cloud or a remote execution environment, such as a VM or Docker container. For more details, you can refer to the documentation here.