TaskOperations operations.
You should not instantiate directly this class, but create a Client instance that will create it for you and attach it as attribute.
ConstructorTaskOperations(client, config, serializer, deserializer)Adds a Task to the specified Job.
The maximum lifetime of a Task from addition to completion is 180 days. If a Task has not completed within 180 days of being added it will be terminated by the Batch service and left in whatever state it was in at that time.
add_collectionAdds a collection of tasks to the specified job.
Note that each task must have a unique ID. The Batch service may not return the results for each task in the same order the tasks were submitted in this request. If the server times out or the connection is closed during the request, the request may have been partially or fully processed, or not at all. In such cases, the user should re-issue the request. Note that it is up to the user to correctly handle failures when re-issuing a request. For example, you should use the same task IDs during a retry so that if the prior operation succeeded, the retry will not create extra tasks unexpectedly. If the response contains any tasks which failed to add, a client can retry the request. In a retry, it is most efficient to resubmit only tasks that failed to add, and to omit tasks that were successfully added on the first attempt. The maximum lifetime of a task from addition to completion is 180 days. If a task has not completed within 180 days of being added it will be terminated by the Batch service and left in whatever state it was in at that time.
deleteDeletes a Task from the specified Job.
When a Task is deleted, all of the files in its directory on the Compute Node where it ran are also deleted (regardless of the retention time). For multi-instance Tasks, the delete Task operation applies synchronously to the primary task; subtasks and their files are then deleted asynchronously in the background.
getGets information about the specified Task.
For multi-instance Tasks, information such as affinityId, executionInfo and nodeInfo refer to the primary Task. Use the list subtasks API to retrieve information about subtasks.
listLists all of the Tasks that are associated with the specified Job.
For multi-instance Tasks, information such as affinityId, executionInfo and nodeInfo refer to the primary Task. Use the list subtasks API to retrieve information about subtasks.
list_subtasksLists all of the subtasks that are associated with the specified multi-instance Task.
If the Task is not a multi-instance Task then this returns an empty collection.
reactivateReactivates a Task, allowing it to run again even if its retry count has been exhausted.
Reactivation makes a Task eligible to be retried again up to its maximum retry count. The Task's state is changed to active. As the Task is no longer in the completed state, any previous exit code or failure information is no longer available after reactivation. Each time a Task is reactivated, its retry count is reset to 0. Reactivation will fail for Tasks that are not completed or that previously completed successfully (with an exit code of 0). Additionally, it will fail if the Job has completed (or is terminating or deleting).
terminateTerminates the specified Task.
When the Task has been terminated, it moves to the completed state. For multi-instance Tasks, the terminate Task operation applies synchronously to the primary task; subtasks are then terminated asynchronously in the background.
updateUpdates the properties of the specified Task.
addAdds a Task to the specified Job.
The maximum lifetime of a Task from addition to completion is 180 days. If a Task has not completed within 180 days of being added it will be terminated by the Batch service and left in whatever state it was in at that time.
add(job_id, task, task_add_options=None, custom_headers=None, raw=False, **operation_config)Adds a collection of tasks to the specified job.
Note that each task must have a unique ID. The Batch service may not return the results for each task in the same order the tasks were submitted in this request. If the server times out or the connection is closed during the request, the request may have been partially or fully processed, or not at all. In such cases, the user should re-issue the request. Note that it is up to the user to correctly handle failures when re-issuing a request. For example, you should use the same task IDs during a retry so that if the prior operation succeeded, the retry will not create extra tasks unexpectedly. If the response contains any tasks which failed to add, a client can retry the request. In a retry, it is most efficient to resubmit only tasks that failed to add, and to omit tasks that were successfully added on the first attempt. The maximum lifetime of a task from addition to completion is 180 days. If a task has not completed within 180 days of being added it will be terminated by the Batch service and left in whatever state it was in at that time.
add_collection(job_id, value, task_add_collection_options=None, custom_headers=None, raw=False, threads=0, **operation_config)Deletes a Task from the specified Job.
When a Task is deleted, all of the files in its directory on the Compute Node where it ran are also deleted (regardless of the retention time). For multi-instance Tasks, the delete Task operation applies synchronously to the primary task; subtasks and their files are then deleted asynchronously in the background.
delete(job_id, task_id, task_delete_options=None, custom_headers=None, raw=False, **operation_config)Gets information about the specified Task.
For multi-instance Tasks, information such as affinityId, executionInfo and nodeInfo refer to the primary Task. Use the list subtasks API to retrieve information about subtasks.
get(job_id, task_id, task_get_options=None, custom_headers=None, raw=False, **operation_config)Lists all of the Tasks that are associated with the specified Job.
For multi-instance Tasks, information such as affinityId, executionInfo and nodeInfo refer to the primary Task. Use the list subtasks API to retrieve information about subtasks.
list(job_id, task_list_options=None, custom_headers=None, raw=False, **operation_config)Lists all of the subtasks that are associated with the specified multi-instance Task.
If the Task is not a multi-instance Task then this returns an empty collection.
list_subtasks(job_id, task_id, task_list_subtasks_options=None, custom_headers=None, raw=False, **operation_config)Reactivates a Task, allowing it to run again even if its retry count has been exhausted.
Reactivation makes a Task eligible to be retried again up to its maximum retry count. The Task's state is changed to active. As the Task is no longer in the completed state, any previous exit code or failure information is no longer available after reactivation. Each time a Task is reactivated, its retry count is reset to 0. Reactivation will fail for Tasks that are not completed or that previously completed successfully (with an exit code of 0). Additionally, it will fail if the Job has completed (or is terminating or deleting).
reactivate(job_id, task_id, task_reactivate_options=None, custom_headers=None, raw=False, **operation_config)Terminates the specified Task.
When the Task has been terminated, it moves to the completed state. For multi-instance Tasks, the terminate Task operation applies synchronously to the primary task; subtasks are then terminated asynchronously in the background.
terminate(job_id, task_id, task_terminate_options=None, custom_headers=None, raw=False, **operation_config)Updates the properties of the specified Task.
update(job_id, task_id, constraints=None, task_update_options=None, custom_headers=None, raw=False, **operation_config)models = <module 'azure.batch.models' from 'C:\\ToolCache\\Python\\3.11.9\\x64\\Lib\\site-packages\\py2docfx\\venv\\venv17\\Lib\\site-packages\\azure\\batch\\models\\__init__.py'>RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4