Stop the pipeline asynchronously by updating the desired state.
There are two variants:
/stop?force=false(default): the pipeline will first atomically checkpoint before deprovisioning the compute resources. When resuming, the pipeline will start from this/stop?force=true: the compute resources will be immediately deprovisioned. When resuming, it will pick up the latest checkpoint made by the periodic checkpointer or by a prior/checkpointcall.
The endpoint returns immediately after setting the desired state to Suspended for
?force=false or Stopped for ?force=true. In the former case, once the pipeline has
successfully passes the Suspending state, the desired state will become Stopped as well.
The procedure to get to the desired state is performed asynchronously. Progress should be
monitored by polling the pipeline GET endpoints.
Note the following:
- The suspending that is done with
/stop?force=falseis not guaranteed to succeed: - If an error is returned during the suspension, the pipeline will be forcefully stopped with that error set
- Otherwise, it will keep trying to suspend, in which case it is possible to cancel suspending
by calling
/stop?force=true /stop?force=truecannot be cancelled: the pipeline must first reachStoppedbefore another action can be done- A pipeline which is in the process of suspending or stopping can only be forcefully stopped
| Path Parameters |
|---|
pipeline_name string — REQUIREDUnique pipeline name |
| Query Parameters |
|---|
force booleanThe |
| Responses | ||||
|---|---|---|---|---|
202Action is accepted and is being performed | ||||
400Action could not be performed
| ||||
404Pipeline with that name does not exist
| ||||
405Action is not supported
| ||||
500
| ||||
501Action is not implemented because it is only available in the Enterprise edition
| ||||
503Action can not be performed (maybe because the pipeline is already suspended)
|