Link Search Menu Expand Document Documentation Menu
Documentation

You're viewing version 2.16 of the OpenSearch documentation. This version is no longer maintained. For the latest version, see the current documentation. For information about OpenSearch version maintenance, see Release Schedule and Maintenance Policy.

Deprovision a workflow

When you no longer need a workflow, you can deprovision its resources. Most workflow steps that create a resource have corresponding workflow steps to reverse that action. To retrieve all resources currently created for a workflow, call the Get Workflow Status API. When you call the Deprovision Workflow API, resources included in the resources_created field of the Get Workflow Status API response will be removed using a workflow step corresponding to the one that provisioned them.

The workflow executes the provisioning steps in reverse order. If a failure occurs because of a resource dependency, such as trying to delete a registered model that is still deployed, then the workflow retries the failing step as long as at least one resource was deleted.

To prevent data loss, resources created using the create_index, create_search_pipeline, and create_ingest_pipeline steps require the resource ID to be included in the allow_delete parameter.

Path and HTTP methods

POST /_plugins/_flow_framework/workflow/<workflow_id>/_deprovision

Path parameters

The following table lists the available path parameters.

Parameter Data type Description
workflow_id String The ID of the workflow to be deprovisioned. Required.
allow-delete String A comma-separated list of resource IDs to be deprovisioned. Required if deleting resources of type index_name or pipeline_id.

Example request

POST /_plugins/_flow_framework/workflow/8xL8bowB8y25Tqfenm50/_deprovision

Example response

If deprovisioning is successful, OpenSearch responds with the same workflow_id that was used in the request:

{
  "workflow_id" : "8xL8bowB8y25Tqfenm50"
}

If deprovisioning did not completely remove all resources, OpenSearch responds with a 202 (ACCEPTED) status and identifies the resources that were not deprovisioned:

{
    "error": "Failed to deprovision some resources: [connector_id Lw7PX4wBfVtHp98y06wV]."
}

In some cases, the failure happens because of another dependent resource that took some time to be removed. In this case, you can attempt to send the same request again.

If deprovisioning required the allow_delete parameter, then OpenSearch responds with a 403 (FORBIDDEN) status and identifies the resources that were not deprovisioned:

{
    "error": "These resources require the allow_delete parameter to deprovision: [index_name my-index]."
}

To obtain a more detailed deprovisioning status than is provided by the summary in the error response, query the Get Workflow Status API.

On success, the workflow returns to a NOT_STARTED state. If some resources have not yet been removed, they are provided in the response.

350 characters left

Have a question? .

Want to contribute? or .