BatchClient class
Client class for accessing Azure Batch service.
Constructors
| Batch |
Methods
| create |
The Batch service supports two ways to control the work done as part of a Job. In the first approach, the user specifies a Job Manager Task. The Batch service launches this Task when it is ready to start the Job. The Job Manager Task controls all other Tasks that run under this Job, by using the Task APIs. In the second approach, the user directly controls the execution of Tasks under an active Job, by using the Task APIs. Also note: when naming Jobs, avoid including sensitive information such as user names or secret project names. This information may appear in telemetry logs accessible to Microsoft Support engineers. |
| create |
Creates a Job Schedule to the specified Account. |
| create |
You can add a user Account to a Compute Node only when it is in the idle or running state. Before you can remotely login to a Compute Node you must configure access ports for SSH and RDP. For more information, see https://learn.microsoft.com/azure/batch/pool-endpoint-configuration |
| create |
When naming Pools, avoid including sensitive information such as user names or secret project names. This information may appear in telemetry logs accessible to Microsoft Support engineers. |
| create |
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. |
| create |
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. |
| deallocate |
You can deallocate a Compute Node only if it is in an idle or running state. |
| delete |
Deleting a Job also deletes all Tasks that are part of that Job, and all Job statistics. This also overrides the retention period for Task data; that is, if the Job contains Tasks which are still retained on Compute Nodes, the Batch services deletes those Tasks' working directories and all their contents. When a Delete Job request is received, the Batch service sets the Job to the deleting state. All update operations on a Job that is in deleting state will fail with status code 409 (Conflict), with additional information indicating that the Job is being deleted. |
| delete |
When you delete a Job Schedule, this also deletes all Jobs and Tasks under that schedule. When Tasks are deleted, all the files in their working directories on the Compute Nodes are also deleted (the retention period is ignored). The Job Schedule statistics are no longer accessible once the Job Schedule is deleted, though they are still counted towards Account lifetime statistics. |
| delete |
Deletes the specified file from the Compute Node. |
| delete |
You can delete a user Account to a Compute Node only when it is in the idle or running state. Before you can remotely login to a Compute Node you must configure access ports for SSH and RDP. For more information, see https://learn.microsoft.com/azure/batch/pool-endpoint-configuration |
| delete |
When you request that a Pool be deleted, the following actions occur: the Pool state is set to deleting; any ongoing resize operation on the Pool are stopped; the Batch service starts resizing the Pool to zero Compute Nodes; any Tasks running on existing Compute Nodes are terminated and requeued (as if a resize Pool operation had been requested with the default requeue option); finally, the Pool is removed from the system. Because running Tasks are requeued, the user can rerun these Tasks by updating their Job to target a different Pool. The Tasks can then run on the new Pool. If you want to override the requeue behavior, then you should call resize Pool explicitly to shrink the Pool to zero size before deleting the Pool. If you call an Update, Patch or Delete API on a Pool in the deleting state, it will fail with HTTP status code 409 with error code PoolBeingDeleted. |
| delete |
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 |
Deletes the specified Task file from the Compute Node where the Task ran. |
| disable |
The Batch Service immediately moves the Job to the disabling state. Batch then uses the disableTasks parameter to determine what to do with the currently running Tasks of the Job. The Job remains in the disabling state until the disable operation is completed and all Tasks have been dealt with according to the disableTasks option; the Job then moves to the disabled state. No new Tasks are started under the Job until it moves back to active state. If you try to disable a Job that is in any state other than active, disabling, or disabled, the request fails with status code 409. |
| disable |
No new Jobs will be created until the Job Schedule is enabled again. |
| disable |
You can disable Task scheduling on a Compute Node only if its current scheduling state is enabled. |
| disable |
Disables automatic scaling for a Pool. |
| enable |
When you call this API, the Batch service sets a disabled Job to the enabling state. After the this operation is completed, the Job moves to the active state, and scheduling of new Tasks under the Job resumes. The Batch service does not allow a Task to remain in the active state for more than 180 days. Therefore, if you enable a Job containing active Tasks which were added more than 180 days ago, those Tasks will not run. |
| enable |
Enables a Job Schedule. |
| enable |
You can enable Task scheduling on a Compute Node only if its current scheduling state is disabled |
| enable |
You cannot enable automatic scaling on a Pool if a resize operation is in progress on the Pool. If automatic scaling of the Pool is currently disabled, you must specify a valid autoscale formula as part of the request. If automatic scaling of the Pool is already enabled, you may specify a new autoscale formula and/or a new evaluation interval. You cannot call this API for the same Pool more than once every 30 seconds. |
| evaluate |
This API is primarily for validating an autoscale formula, as it simply returns the result without applying the formula to the Pool. The Pool must have auto scaling enabled in order to evaluate a formula. |
| get |
This operation returns only Applications and versions that are available for use on Compute Nodes; that is, that can be used in an Package reference. For administrator information about Applications and versions that are not yet available to Compute Nodes, use the Azure portal or the Azure Resource Manager API. |
| get |
Gets information about the specified Job. |
| get |
Gets information about the specified Job Schedule. |
| get |
Task counts provide a count of the Tasks by active, running or completed Task state, and a count of Tasks which succeeded or failed. Tasks in the preparing state are counted as running. Note that the numbers returned may not always be up to date. If you need exact task counts, use a list query. |
| get |
Gets information about the specified Compute Node. |
| get |
Gets information about the specified Compute Node Extension. |
| get |
Returns the content of the specified Compute Node file. |
| get |
Gets the properties of the specified Compute Node file. |
| get |
Before you can remotely login to a Compute Node using the remote login settings, you must create a user Account on the Compute Node and configure access ports for SSH and RDP. For more information, see https://learn.microsoft.com/azure/batch/pool-endpoint-configuration |
| get |
Gets information about the specified Pool. |
| get |
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 |
Returns the content of the specified Task file. |
| get |
Gets the properties of the specified Task file. |
| job |
Checks the specified Job Schedule exists. |
| list |
This operation returns only Applications and versions that are available for use on Compute Nodes; that is, that can be used in an Package reference. For administrator information about applications and versions that are not yet available to Compute Nodes, use the Azure portal or the Azure Resource Manager API. |
| list |
This API returns the Job Preparation and Job Release Task status on all Compute Nodes that have run the Job Preparation or Job Release Task. This includes Compute Nodes which have since been removed from the Pool. If this API is invoked on a Job which has no Job Preparation or Job Release Task, the Batch service returns HTTP status code 409 (Conflict) with an error code of JobPreparationTaskNotSpecified. |
| list |
Lists all of the Jobs in the specified Account. |
| list |
Lists all of the Job Schedules in the specified Account. |
| list |
Lists the Jobs that have been created under the specified Job Schedule. |
| list |
Lists the Compute Nodes Extensions in the specified Pool. |
| list |
Lists all of the files in Task directories on the specified Compute Node. |
| list |
Lists the Compute Nodes in the specified Pool. |
| list |
Gets the number of Compute Nodes in each state, grouped by Pool. Note that the numbers returned may not always be up to date. If you need exact node counts, use a list query. |
| list |
Lists all of the Pools in the specified Account. |
| list |
If you do not specify a $filter clause including a poolId, the response includes all Pools that existed in the Account in the time range of the returned aggregation intervals. If you do not specify a $filter clause including a startTime or endTime these filters default to the start and end times of the last aggregation interval currently available; that is, only the last aggregation interval is returned. |
| list |
If the Task is not a multi-instance Task then this returns an empty collection. |
| list |
Lists all Virtual Machine Images supported by the Azure Batch service. |
| list |
Lists the files in a Task's directory on its Compute Node. |
| list |
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. |
| pool |
Gets basic properties of a Pool. |
| reactivate |
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). |
| reboot |
You can restart a Compute Node only if it is in an idle or running state. |
| reimage |
You can reinstall the operating system on a Compute Node only if it is in an idle or running state. This API can be invoked only on Pools created with the cloud service configuration property. |
| remove |
This operation can only run when the allocation state of the Pool is steady. When this operation runs, the allocation state changes from steady to resizing. Each request may remove up to 100 nodes. |
| replace |
This fully replaces all the updatable properties of the Job. For example, if the Job has constraints associated with it and if constraints is not specified with this request, then the Batch service will remove the existing constraints. |
| replace |
This fully replaces all the updatable properties of the Job Schedule. For example, if the schedule property is not specified with this request, then the Batch service will remove the existing schedule. Changes to a Job Schedule only impact Jobs created by the schedule after the update has taken place; currently running Jobs are unaffected. |
| replace |
This operation replaces of all the updatable properties of the Account. For example, if the expiryTime element is not specified, the current value is replaced with the default value, not left unmodified. You can update a user Account on a Compute Node only when it is in the idle or running state. |
| replace |
This fully replaces all the updatable properties of the Pool. For example, if the Pool has a StartTask associated with it and if StartTask is not specified with this request, then the Batch service will remove the existing StartTask. |
| replace |
Updates the properties of the specified Task. |
| resize |
You can only resize a Pool when its allocation state is steady. If the Pool is already resizing, the request fails with status code 409. When you resize a Pool, the Pool's allocation state changes from steady to resizing. You cannot resize Pools which are configured for automatic scaling. If you try to do this, the Batch service returns an error 409. If you resize a Pool downwards, the Batch service chooses which Compute Nodes to remove. To remove specific Compute Nodes, use the Pool remove Compute Nodes API instead. |
| start |
You can start a Compute Node only if it has been deallocated. |
| stop |
This does not restore the Pool to its previous state before the resize operation: it only stops any further changes being made, and the Pool maintains its current state. After stopping, the Pool stabilizes at the number of Compute Nodes it was at when the stop operation was done. During the stop operation, the Pool allocation state changes first to stopping and then to steady. A resize operation need not be an explicit resize Pool request; this API can also be used to halt the initial sizing of the Pool when it is created. |
| terminate |
When a Terminate Job request is received, the Batch service sets the Job to the terminating state. The Batch service then terminates any running Tasks associated with the Job and runs any required Job release Tasks. Then the Job moves into the completed state. If there are any Tasks in the Job in the active state, they will remain in the active state. Once a Job is terminated, new Tasks cannot be added and any remaining active Tasks will not be scheduled. |
| terminate |
Terminates a Job Schedule. |
| terminate |
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. |
| update |
This replaces only the Job properties specified in the request. For example, if the Job has constraints, and a request does not specify the constraints element, then the Job keeps the existing constraints. |
| update |
This replaces only the Job Schedule properties specified in the request. For example, if the schedule property is not specified with this request, then the Batch service will keep the existing schedule. Changes to a Job Schedule only impact Jobs created by the schedule after the update has taken place; currently running Jobs are unaffected. |
| update |
This only replaces the Pool properties specified in the request. For example, if the Pool has a StartTask associated with it, and a request does not specify a StartTask element, then the Pool keeps the existing StartTask. |
| upload |
This is for gathering Azure Batch service log files in an automated fashion from Compute Nodes if you are experiencing an error and wish to escalate to Azure support. The Azure Batch service log files should be shared with Azure support to aid in debugging issues with the Batch service. |
Constructor Details
BatchClient(string, TokenCredential | AzureNamedKeyCredential, BatchClientOptionalParams)
new BatchClient(endpointParam: string, credential: TokenCredential | AzureNamedKeyCredential, options?: BatchClientOptionalParams)
Parameters
- endpointParam
-
string
- credential
- options
- BatchClientOptionalParams
Method Details
createJob(BatchJobCreateOptions, CreateJobOptionalParams)
The Batch service supports two ways to control the work done as part of a Job. In the first approach, the user specifies a Job Manager Task. The Batch service launches this Task when it is ready to start the Job. The Job Manager Task controls all other Tasks that run under this Job, by using the Task APIs. In the second approach, the user directly controls the execution of Tasks under an active Job, by using the Task APIs. Also note: when naming Jobs, avoid including sensitive information such as user names or secret project names. This information may appear in telemetry logs accessible to Microsoft Support engineers.
function createJob(job: BatchJobCreateOptions, options?: CreateJobOptionalParams): Promise<void>
Parameters
- options
- CreateJobOptionalParams
Returns
Promise<void>
createJobSchedule(BatchJobScheduleCreateOptions, CreateJobScheduleOptionalParams)
Creates a Job Schedule to the specified Account.
function createJobSchedule(jobSchedule: BatchJobScheduleCreateOptions, options?: CreateJobScheduleOptionalParams): Promise<void>
Parameters
- jobSchedule
- BatchJobScheduleCreateOptions
- options
- CreateJobScheduleOptionalParams
Returns
Promise<void>
createNodeUser(string, string, BatchNodeUserCreateOptions, CreateNodeUserOptionalParams)
You can add a user Account to a Compute Node only when it is in the idle or running state. Before you can remotely login to a Compute Node you must configure access ports for SSH and RDP. For more information, see https://learn.microsoft.com/azure/batch/pool-endpoint-configuration
function createNodeUser(poolId: string, nodeId: string, user: BatchNodeUserCreateOptions, options?: CreateNodeUserOptionalParams): Promise<void>
Parameters
- poolId
-
string
- nodeId
-
string
- options
- CreateNodeUserOptionalParams
Returns
Promise<void>
createPool(BatchPoolCreateOptions, CreatePoolOptionalParams)
When naming Pools, avoid including sensitive information such as user names or secret project names. This information may appear in telemetry logs accessible to Microsoft Support engineers.
function createPool(pool: BatchPoolCreateOptions, options?: CreatePoolOptionalParams): Promise<void>
Parameters
- options
- CreatePoolOptionalParams
Returns
Promise<void>
createTask(string, BatchTaskCreateOptions, CreateTaskOptionalParams)
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.
function createTask(jobId: string, task: BatchTaskCreateOptions, options?: CreateTaskOptionalParams): Promise<void>
Parameters
- jobId
-
string
- options
- CreateTaskOptionalParams
Returns
Promise<void>
createTaskCollection(string, BatchTaskGroup, CreateTaskCollectionOptionalParams)
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.
function createTaskCollection(jobId: string, taskCollection: BatchTaskGroup, options?: CreateTaskCollectionOptionalParams): Promise<BatchCreateTaskCollectionResult>
Parameters
- jobId
-
string
- taskCollection
- BatchTaskGroup
Returns
Promise<BatchCreateTaskCollectionResult>
deallocateNode(string, string, DeallocateNodeOptionalParams)
You can deallocate a Compute Node only if it is in an idle or running state.
function deallocateNode(poolId: string, nodeId: string, options?: DeallocateNodeOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- poolId
-
string
- nodeId
-
string
- options
- DeallocateNodeOptionalParams
Returns
PollerLike<OperationState<void>, void>
deleteJob(string, DeleteJobOptionalParams)
Deleting a Job also deletes all Tasks that are part of that Job, and all Job statistics. This also overrides the retention period for Task data; that is, if the Job contains Tasks which are still retained on Compute Nodes, the Batch services deletes those Tasks' working directories and all their contents. When a Delete Job request is received, the Batch service sets the Job to the deleting state. All update operations on a Job that is in deleting state will fail with status code 409 (Conflict), with additional information indicating that the Job is being deleted.
function deleteJob(jobId: string, options?: DeleteJobOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- jobId
-
string
- options
- DeleteJobOptionalParams
Returns
PollerLike<OperationState<void>, void>
deleteJobSchedule(string, DeleteJobScheduleOptionalParams)
When you delete a Job Schedule, this also deletes all Jobs and Tasks under that schedule. When Tasks are deleted, all the files in their working directories on the Compute Nodes are also deleted (the retention period is ignored). The Job Schedule statistics are no longer accessible once the Job Schedule is deleted, though they are still counted towards Account lifetime statistics.
function deleteJobSchedule(jobScheduleId: string, options?: DeleteJobScheduleOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- jobScheduleId
-
string
- options
- DeleteJobScheduleOptionalParams
Returns
PollerLike<OperationState<void>, void>
deleteNodeFile(string, string, string, DeleteNodeFileOptionalParams)
Deletes the specified file from the Compute Node.
function deleteNodeFile(poolId: string, nodeId: string, filePath: string, options?: DeleteNodeFileOptionalParams): Promise<void>
Parameters
- poolId
-
string
- nodeId
-
string
- filePath
-
string
- options
- DeleteNodeFileOptionalParams
Returns
Promise<void>
deleteNodeUser(string, string, string, DeleteNodeUserOptionalParams)
You can delete a user Account to a Compute Node only when it is in the idle or running state. Before you can remotely login to a Compute Node you must configure access ports for SSH and RDP. For more information, see https://learn.microsoft.com/azure/batch/pool-endpoint-configuration
function deleteNodeUser(poolId: string, nodeId: string, userName: string, options?: DeleteNodeUserOptionalParams): Promise<void>
Parameters
- poolId
-
string
- nodeId
-
string
- userName
-
string
- options
- DeleteNodeUserOptionalParams
Returns
Promise<void>
deletePool(string, DeletePoolOptionalParams)
When you request that a Pool be deleted, the following actions occur: the Pool state is set to deleting; any ongoing resize operation on the Pool are stopped; the Batch service starts resizing the Pool to zero Compute Nodes; any Tasks running on existing Compute Nodes are terminated and requeued (as if a resize Pool operation had been requested with the default requeue option); finally, the Pool is removed from the system. Because running Tasks are requeued, the user can rerun these Tasks by updating their Job to target a different Pool. The Tasks can then run on the new Pool. If you want to override the requeue behavior, then you should call resize Pool explicitly to shrink the Pool to zero size before deleting the Pool. If you call an Update, Patch or Delete API on a Pool in the deleting state, it will fail with HTTP status code 409 with error code PoolBeingDeleted.
function deletePool(poolId: string, options?: DeletePoolOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- poolId
-
string
- options
- DeletePoolOptionalParams
Returns
PollerLike<OperationState<void>, void>
deleteTask(string, string, DeleteTaskOptionalParams)
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.
function deleteTask(jobId: string, taskId: string, options?: DeleteTaskOptionalParams): Promise<void>
Parameters
- jobId
-
string
- taskId
-
string
- options
- DeleteTaskOptionalParams
Returns
Promise<void>
deleteTaskFile(string, string, string, DeleteTaskFileOptionalParams)
Deletes the specified Task file from the Compute Node where the Task ran.
function deleteTaskFile(jobId: string, taskId: string, filePath: string, options?: DeleteTaskFileOptionalParams): Promise<void>
Parameters
- jobId
-
string
- taskId
-
string
- filePath
-
string
- options
- DeleteTaskFileOptionalParams
Returns
Promise<void>
disableJob(string, BatchJobDisableOptions, DisableJobOptionalParams)
The Batch Service immediately moves the Job to the disabling state. Batch then uses the disableTasks parameter to determine what to do with the currently running Tasks of the Job. The Job remains in the disabling state until the disable operation is completed and all Tasks have been dealt with according to the disableTasks option; the Job then moves to the disabled state. No new Tasks are started under the Job until it moves back to active state. If you try to disable a Job that is in any state other than active, disabling, or disabled, the request fails with status code 409.
function disableJob(jobId: string, disableOptions: BatchJobDisableOptions, options?: DisableJobOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- jobId
-
string
- disableOptions
- BatchJobDisableOptions
- options
- DisableJobOptionalParams
Returns
PollerLike<OperationState<void>, void>
disableJobSchedule(string, DisableJobScheduleOptionalParams)
No new Jobs will be created until the Job Schedule is enabled again.
function disableJobSchedule(jobScheduleId: string, options?: DisableJobScheduleOptionalParams): Promise<void>
Parameters
- jobScheduleId
-
string
- options
- DisableJobScheduleOptionalParams
Returns
Promise<void>
disableNodeScheduling(string, string, DisableNodeSchedulingOptionalParams)
You can disable Task scheduling on a Compute Node only if its current scheduling state is enabled.
function disableNodeScheduling(poolId: string, nodeId: string, options?: DisableNodeSchedulingOptionalParams): Promise<void>
Parameters
- poolId
-
string
- nodeId
-
string
Returns
Promise<void>
disablePoolAutoScale(string, DisablePoolAutoScaleOptionalParams)
Disables automatic scaling for a Pool.
function disablePoolAutoScale(poolId: string, options?: DisablePoolAutoScaleOptionalParams): Promise<void>
Parameters
- poolId
-
string
Returns
Promise<void>
enableJob(string, EnableJobOptionalParams)
When you call this API, the Batch service sets a disabled Job to the enabling state. After the this operation is completed, the Job moves to the active state, and scheduling of new Tasks under the Job resumes. The Batch service does not allow a Task to remain in the active state for more than 180 days. Therefore, if you enable a Job containing active Tasks which were added more than 180 days ago, those Tasks will not run.
function enableJob(jobId: string, options?: EnableJobOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- jobId
-
string
- options
- EnableJobOptionalParams
Returns
PollerLike<OperationState<void>, void>
enableJobSchedule(string, EnableJobScheduleOptionalParams)
Enables a Job Schedule.
function enableJobSchedule(jobScheduleId: string, options?: EnableJobScheduleOptionalParams): Promise<void>
Parameters
- jobScheduleId
-
string
- options
- EnableJobScheduleOptionalParams
Returns
Promise<void>
enableNodeScheduling(string, string, EnableNodeSchedulingOptionalParams)
You can enable Task scheduling on a Compute Node only if its current scheduling state is disabled
function enableNodeScheduling(poolId: string, nodeId: string, options?: EnableNodeSchedulingOptionalParams): Promise<void>
Parameters
- poolId
-
string
- nodeId
-
string
Returns
Promise<void>
enablePoolAutoScale(string, BatchPoolEnableAutoScaleOptions, EnablePoolAutoScaleOptionalParams)
You cannot enable automatic scaling on a Pool if a resize operation is in progress on the Pool. If automatic scaling of the Pool is currently disabled, you must specify a valid autoscale formula as part of the request. If automatic scaling of the Pool is already enabled, you may specify a new autoscale formula and/or a new evaluation interval. You cannot call this API for the same Pool more than once every 30 seconds.
function enablePoolAutoScale(poolId: string, enableAutoScaleOptions: BatchPoolEnableAutoScaleOptions, options?: EnablePoolAutoScaleOptionalParams): Promise<void>
Parameters
- poolId
-
string
- enableAutoScaleOptions
- BatchPoolEnableAutoScaleOptions
Returns
Promise<void>
evaluatePoolAutoScale(string, BatchPoolEvaluateAutoScaleOptions, EvaluatePoolAutoScaleOptionalParams)
This API is primarily for validating an autoscale formula, as it simply returns the result without applying the formula to the Pool. The Pool must have auto scaling enabled in order to evaluate a formula.
function evaluatePoolAutoScale(poolId: string, evaluateAutoScaleOptions: BatchPoolEvaluateAutoScaleOptions, options?: EvaluatePoolAutoScaleOptionalParams): Promise<AutoScaleRun>
Parameters
- poolId
-
string
- evaluateAutoScaleOptions
- BatchPoolEvaluateAutoScaleOptions
Returns
Promise<AutoScaleRun>
getApplication(string, GetApplicationOptionalParams)
This operation returns only Applications and versions that are available for use on Compute Nodes; that is, that can be used in an Package reference. For administrator information about Applications and versions that are not yet available to Compute Nodes, use the Azure portal or the Azure Resource Manager API.
function getApplication(applicationId: string, options?: GetApplicationOptionalParams): Promise<BatchApplication>
Parameters
- applicationId
-
string
- options
- GetApplicationOptionalParams
Returns
Promise<BatchApplication>
getJob(string, GetJobOptionalParams)
Gets information about the specified Job.
function getJob(jobId: string, options?: GetJobOptionalParams): Promise<BatchJob>
Parameters
- jobId
-
string
- options
- GetJobOptionalParams
Returns
Promise<BatchJob>
getJobSchedule(string, GetJobScheduleOptionalParams)
Gets information about the specified Job Schedule.
function getJobSchedule(jobScheduleId: string, options?: GetJobScheduleOptionalParams): Promise<BatchJobSchedule>
Parameters
- jobScheduleId
-
string
- options
- GetJobScheduleOptionalParams
Returns
Promise<BatchJobSchedule>
getJobTaskCounts(string, GetJobTaskCountsOptionalParams)
Task counts provide a count of the Tasks by active, running or completed Task state, and a count of Tasks which succeeded or failed. Tasks in the preparing state are counted as running. Note that the numbers returned may not always be up to date. If you need exact task counts, use a list query.
function getJobTaskCounts(jobId: string, options?: GetJobTaskCountsOptionalParams): Promise<BatchTaskCountsResult>
Parameters
- jobId
-
string
- options
- GetJobTaskCountsOptionalParams
Returns
Promise<BatchTaskCountsResult>
getNode(string, string, GetNodeOptionalParams)
Gets information about the specified Compute Node.
function getNode(poolId: string, nodeId: string, options?: GetNodeOptionalParams): Promise<BatchNode>
Parameters
- poolId
-
string
- nodeId
-
string
- options
- GetNodeOptionalParams
Returns
Promise<BatchNode>
getNodeExtension(string, string, string, GetNodeExtensionOptionalParams)
Gets information about the specified Compute Node Extension.
function getNodeExtension(poolId: string, nodeId: string, extensionName: string, options?: GetNodeExtensionOptionalParams): Promise<BatchNodeVMExtension>
Parameters
- poolId
-
string
- nodeId
-
string
- extensionName
-
string
- options
- GetNodeExtensionOptionalParams
Returns
Promise<BatchNodeVMExtension>
getNodeFile(string, string, string, GetNodeFileOptionalParams)
Returns the content of the specified Compute Node file.
function getNodeFile(poolId: string, nodeId: string, filePath: string, options?: GetNodeFileOptionalParams): Promise<Uint8Array>
Parameters
- poolId
-
string
- nodeId
-
string
- filePath
-
string
- options
- GetNodeFileOptionalParams
Returns
Promise<Uint8Array>
getNodeFileProperties(string, string, string, GetNodeFilePropertiesOptionalParams)
Gets the properties of the specified Compute Node file.
function getNodeFileProperties(poolId: string, nodeId: string, filePath: string, options?: GetNodeFilePropertiesOptionalParams): Promise<BatchNodeFile>
Parameters
- poolId
-
string
- nodeId
-
string
- filePath
-
string
Returns
Promise<BatchNodeFile>
getNodeRemoteLoginSettings(string, string, GetNodeRemoteLoginSettingsOptionalParams)
Before you can remotely login to a Compute Node using the remote login settings, you must create a user Account on the Compute Node and configure access ports for SSH and RDP. For more information, see https://learn.microsoft.com/azure/batch/pool-endpoint-configuration
function getNodeRemoteLoginSettings(poolId: string, nodeId: string, options?: GetNodeRemoteLoginSettingsOptionalParams): Promise<BatchNodeRemoteLoginSettings>
Parameters
- poolId
-
string
- nodeId
-
string
Returns
Promise<BatchNodeRemoteLoginSettings>
getPool(string, GetPoolOptionalParams)
Gets information about the specified Pool.
function getPool(poolId: string, options?: GetPoolOptionalParams): Promise<BatchPool>
Parameters
- poolId
-
string
- options
- GetPoolOptionalParams
Returns
Promise<BatchPool>
getTask(string, string, GetTaskOptionalParams)
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.
function getTask(jobId: string, taskId: string, options?: GetTaskOptionalParams): Promise<BatchTask>
Parameters
- jobId
-
string
- taskId
-
string
- options
- GetTaskOptionalParams
Returns
Promise<BatchTask>
getTaskFile(string, string, string, GetTaskFileOptionalParams)
Returns the content of the specified Task file.
function getTaskFile(jobId: string, taskId: string, filePath: string, options?: GetTaskFileOptionalParams): Promise<Uint8Array>
Parameters
- jobId
-
string
- taskId
-
string
- filePath
-
string
- options
- GetTaskFileOptionalParams
Returns
Promise<Uint8Array>
getTaskFileProperties(string, string, string, GetTaskFilePropertiesOptionalParams)
Gets the properties of the specified Task file.
function getTaskFileProperties(jobId: string, taskId: string, filePath: string, options?: GetTaskFilePropertiesOptionalParams): Promise<BatchNodeFile>
Parameters
- jobId
-
string
- taskId
-
string
- filePath
-
string
Returns
Promise<BatchNodeFile>
jobScheduleExists(string, JobScheduleExistsOptionalParams)
Checks the specified Job Schedule exists.
function jobScheduleExists(jobScheduleId: string, options?: JobScheduleExistsOptionalParams): Promise<boolean>
Parameters
- jobScheduleId
-
string
- options
- JobScheduleExistsOptionalParams
Returns
Promise<boolean>
listApplications(ListApplicationsOptionalParams)
This operation returns only Applications and versions that are available for use on Compute Nodes; that is, that can be used in an Package reference. For administrator information about applications and versions that are not yet available to Compute Nodes, use the Azure portal or the Azure Resource Manager API.
function listApplications(options?: ListApplicationsOptionalParams): PagedAsyncIterableIterator<BatchApplication, BatchApplication[], PageSettings>
Parameters
- options
- ListApplicationsOptionalParams
Returns
listJobPreparationAndReleaseTaskStatus(string, ListJobPreparationAndReleaseTaskStatusOptionalParams)
This API returns the Job Preparation and Job Release Task status on all Compute Nodes that have run the Job Preparation or Job Release Task. This includes Compute Nodes which have since been removed from the Pool. If this API is invoked on a Job which has no Job Preparation or Job Release Task, the Batch service returns HTTP status code 409 (Conflict) with an error code of JobPreparationTaskNotSpecified.
function listJobPreparationAndReleaseTaskStatus(jobId: string, options?: ListJobPreparationAndReleaseTaskStatusOptionalParams): PagedAsyncIterableIterator<BatchJobPreparationAndReleaseTaskStatus, BatchJobPreparationAndReleaseTaskStatus[], PageSettings>
Parameters
- jobId
-
string
Returns
listJobs(ListJobsOptionalParams)
Lists all of the Jobs in the specified Account.
function listJobs(options?: ListJobsOptionalParams): PagedAsyncIterableIterator<BatchJob, BatchJob[], PageSettings>
Parameters
- options
- ListJobsOptionalParams
Returns
listJobSchedules(ListJobSchedulesOptionalParams)
Lists all of the Job Schedules in the specified Account.
function listJobSchedules(options?: ListJobSchedulesOptionalParams): PagedAsyncIterableIterator<BatchJobSchedule, BatchJobSchedule[], PageSettings>
Parameters
- options
- ListJobSchedulesOptionalParams
Returns
listJobsFromSchedule(string, ListJobsFromScheduleOptionalParams)
Lists the Jobs that have been created under the specified Job Schedule.
function listJobsFromSchedule(jobScheduleId: string, options?: ListJobsFromScheduleOptionalParams): PagedAsyncIterableIterator<BatchJob, BatchJob[], PageSettings>
Parameters
- jobScheduleId
-
string
Returns
listNodeExtensions(string, string, ListNodeExtensionsOptionalParams)
Lists the Compute Nodes Extensions in the specified Pool.
function listNodeExtensions(poolId: string, nodeId: string, options?: ListNodeExtensionsOptionalParams): PagedAsyncIterableIterator<BatchNodeVMExtension, BatchNodeVMExtension[], PageSettings>
Parameters
- poolId
-
string
- nodeId
-
string
- options
- ListNodeExtensionsOptionalParams
Returns
listNodeFiles(string, string, ListNodeFilesOptionalParams)
Lists all of the files in Task directories on the specified Compute Node.
function listNodeFiles(poolId: string, nodeId: string, options?: ListNodeFilesOptionalParams): PagedAsyncIterableIterator<BatchNodeFile, BatchNodeFile[], PageSettings>
Parameters
- poolId
-
string
- nodeId
-
string
- options
- ListNodeFilesOptionalParams
Returns
listNodes(string, ListNodesOptionalParams)
Lists the Compute Nodes in the specified Pool.
function listNodes(poolId: string, options?: ListNodesOptionalParams): PagedAsyncIterableIterator<BatchNode, BatchNode[], PageSettings>
Parameters
- poolId
-
string
- options
- ListNodesOptionalParams
Returns
listPoolNodeCounts(ListPoolNodeCountsOptionalParams)
Gets the number of Compute Nodes in each state, grouped by Pool. Note that the numbers returned may not always be up to date. If you need exact node counts, use a list query.
function listPoolNodeCounts(options?: ListPoolNodeCountsOptionalParams): PagedAsyncIterableIterator<BatchPoolNodeCounts, BatchPoolNodeCounts[], PageSettings>
Parameters
- options
- ListPoolNodeCountsOptionalParams
Returns
listPools(ListPoolsOptionalParams)
Lists all of the Pools in the specified Account.
function listPools(options?: ListPoolsOptionalParams): PagedAsyncIterableIterator<BatchPool, BatchPool[], PageSettings>
Parameters
- options
- ListPoolsOptionalParams
Returns
listPoolUsageMetrics(ListPoolUsageMetricsOptionalParams)
If you do not specify a $filter clause including a poolId, the response includes all Pools that existed in the Account in the time range of the returned aggregation intervals. If you do not specify a $filter clause including a startTime or endTime these filters default to the start and end times of the last aggregation interval currently available; that is, only the last aggregation interval is returned.
function listPoolUsageMetrics(options?: ListPoolUsageMetricsOptionalParams): PagedAsyncIterableIterator<BatchPoolUsageMetrics, BatchPoolUsageMetrics[], PageSettings>
Parameters
Returns
listSubTasks(string, string, ListSubTasksOptionalParams)
If the Task is not a multi-instance Task then this returns an empty collection.
function listSubTasks(jobId: string, taskId: string, options?: ListSubTasksOptionalParams): PagedAsyncIterableIterator<BatchSubtask, BatchSubtask[], PageSettings>
Parameters
- jobId
-
string
- taskId
-
string
- options
- ListSubTasksOptionalParams
Returns
listSupportedImages(ListSupportedImagesOptionalParams)
Lists all Virtual Machine Images supported by the Azure Batch service.
function listSupportedImages(options?: ListSupportedImagesOptionalParams): PagedAsyncIterableIterator<BatchSupportedImage, BatchSupportedImage[], PageSettings>
Parameters
Returns
listTaskFiles(string, string, ListTaskFilesOptionalParams)
Lists the files in a Task's directory on its Compute Node.
function listTaskFiles(jobId: string, taskId: string, options?: ListTaskFilesOptionalParams): PagedAsyncIterableIterator<BatchNodeFile, BatchNodeFile[], PageSettings>
Parameters
- jobId
-
string
- taskId
-
string
- options
- ListTaskFilesOptionalParams
Returns
listTasks(string, ListTasksOptionalParams)
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.
function listTasks(jobId: string, options?: ListTasksOptionalParams): PagedAsyncIterableIterator<BatchTask, BatchTask[], PageSettings>
Parameters
- jobId
-
string
- options
- ListTasksOptionalParams
Returns
poolExists(string, PoolExistsOptionalParams)
Gets basic properties of a Pool.
function poolExists(poolId: string, options?: PoolExistsOptionalParams): Promise<boolean>
Parameters
- poolId
-
string
- options
- PoolExistsOptionalParams
Returns
Promise<boolean>
reactivateTask(string, string, ReactivateTaskOptionalParams)
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).
function reactivateTask(jobId: string, taskId: string, options?: ReactivateTaskOptionalParams): Promise<void>
Parameters
- jobId
-
string
- taskId
-
string
- options
- ReactivateTaskOptionalParams
Returns
Promise<void>
rebootNode(string, string, RebootNodeOptionalParams)
You can restart a Compute Node only if it is in an idle or running state.
function rebootNode(poolId: string, nodeId: string, options?: RebootNodeOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- poolId
-
string
- nodeId
-
string
- options
- RebootNodeOptionalParams
Returns
PollerLike<OperationState<void>, void>
reimageNode(string, string, ReimageNodeOptionalParams)
You can reinstall the operating system on a Compute Node only if it is in an idle or running state. This API can be invoked only on Pools created with the cloud service configuration property.
function reimageNode(poolId: string, nodeId: string, options?: ReimageNodeOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- poolId
-
string
- nodeId
-
string
- options
- ReimageNodeOptionalParams
Returns
PollerLike<OperationState<void>, void>
removeNodes(string, BatchNodeRemoveOptions, RemoveNodesOptionalParams)
This operation can only run when the allocation state of the Pool is steady. When this operation runs, the allocation state changes from steady to resizing. Each request may remove up to 100 nodes.
function removeNodes(poolId: string, removeOptions: BatchNodeRemoveOptions, options?: RemoveNodesOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- poolId
-
string
- removeOptions
- BatchNodeRemoveOptions
- options
- RemoveNodesOptionalParams
Returns
PollerLike<OperationState<void>, void>
replaceJob(string, BatchJob, ReplaceJobOptionalParams)
This fully replaces all the updatable properties of the Job. For example, if the Job has constraints associated with it and if constraints is not specified with this request, then the Batch service will remove the existing constraints.
function replaceJob(jobId: string, job: BatchJob, options?: ReplaceJobOptionalParams): Promise<void>
Parameters
- jobId
-
string
- job
- BatchJob
- options
- ReplaceJobOptionalParams
Returns
Promise<void>
replaceJobSchedule(string, BatchJobSchedule, ReplaceJobScheduleOptionalParams)
This fully replaces all the updatable properties of the Job Schedule. For example, if the schedule property is not specified with this request, then the Batch service will remove the existing schedule. Changes to a Job Schedule only impact Jobs created by the schedule after the update has taken place; currently running Jobs are unaffected.
function replaceJobSchedule(jobScheduleId: string, jobSchedule: BatchJobSchedule, options?: ReplaceJobScheduleOptionalParams): Promise<void>
Parameters
- jobScheduleId
-
string
- jobSchedule
- BatchJobSchedule
- options
- ReplaceJobScheduleOptionalParams
Returns
Promise<void>
replaceNodeUser(string, string, string, BatchNodeUserUpdateOptions, ReplaceNodeUserOptionalParams)
This operation replaces of all the updatable properties of the Account. For example, if the expiryTime element is not specified, the current value is replaced with the default value, not left unmodified. You can update a user Account on a Compute Node only when it is in the idle or running state.
function replaceNodeUser(poolId: string, nodeId: string, userName: string, updateOptions: BatchNodeUserUpdateOptions, options?: ReplaceNodeUserOptionalParams): Promise<void>
Parameters
- poolId
-
string
- nodeId
-
string
- userName
-
string
- updateOptions
- BatchNodeUserUpdateOptions
- options
- ReplaceNodeUserOptionalParams
Returns
Promise<void>
replacePoolProperties(string, BatchPoolReplaceOptions, ReplacePoolPropertiesOptionalParams)
This fully replaces all the updatable properties of the Pool. For example, if the Pool has a StartTask associated with it and if StartTask is not specified with this request, then the Batch service will remove the existing StartTask.
function replacePoolProperties(poolId: string, pool: BatchPoolReplaceOptions, options?: ReplacePoolPropertiesOptionalParams): Promise<void>
Parameters
- poolId
-
string
Returns
Promise<void>
replaceTask(string, string, BatchTask, ReplaceTaskOptionalParams)
Updates the properties of the specified Task.
function replaceTask(jobId: string, taskId: string, task: BatchTask, options?: ReplaceTaskOptionalParams): Promise<void>
Parameters
- jobId
-
string
- taskId
-
string
- task
- BatchTask
- options
- ReplaceTaskOptionalParams
Returns
Promise<void>
resizePool(string, BatchPoolResizeOptions, ResizePoolOptionalParams)
You can only resize a Pool when its allocation state is steady. If the Pool is already resizing, the request fails with status code 409. When you resize a Pool, the Pool's allocation state changes from steady to resizing. You cannot resize Pools which are configured for automatic scaling. If you try to do this, the Batch service returns an error 409. If you resize a Pool downwards, the Batch service chooses which Compute Nodes to remove. To remove specific Compute Nodes, use the Pool remove Compute Nodes API instead.
function resizePool(poolId: string, resizeOptions: BatchPoolResizeOptions, options?: ResizePoolOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- poolId
-
string
- resizeOptions
- BatchPoolResizeOptions
- options
- ResizePoolOptionalParams
Returns
PollerLike<OperationState<void>, void>
startNode(string, string, StartNodeOptionalParams)
You can start a Compute Node only if it has been deallocated.
function startNode(poolId: string, nodeId: string, options?: StartNodeOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- poolId
-
string
- nodeId
-
string
- options
- StartNodeOptionalParams
Returns
PollerLike<OperationState<void>, void>
stopPoolResize(string, StopPoolResizeOptionalParams)
This does not restore the Pool to its previous state before the resize operation: it only stops any further changes being made, and the Pool maintains its current state. After stopping, the Pool stabilizes at the number of Compute Nodes it was at when the stop operation was done. During the stop operation, the Pool allocation state changes first to stopping and then to steady. A resize operation need not be an explicit resize Pool request; this API can also be used to halt the initial sizing of the Pool when it is created.
function stopPoolResize(poolId: string, options?: StopPoolResizeOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- poolId
-
string
- options
- StopPoolResizeOptionalParams
Returns
PollerLike<OperationState<void>, void>
terminateJob(string, TerminateJobOptionalParams)
When a Terminate Job request is received, the Batch service sets the Job to the terminating state. The Batch service then terminates any running Tasks associated with the Job and runs any required Job release Tasks. Then the Job moves into the completed state. If there are any Tasks in the Job in the active state, they will remain in the active state. Once a Job is terminated, new Tasks cannot be added and any remaining active Tasks will not be scheduled.
function terminateJob(jobId: string, options?: TerminateJobOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- jobId
-
string
- options
- TerminateJobOptionalParams
Returns
PollerLike<OperationState<void>, void>
terminateJobSchedule(string, TerminateJobScheduleOptionalParams)
Terminates a Job Schedule.
function terminateJobSchedule(jobScheduleId: string, options?: TerminateJobScheduleOptionalParams): PollerLike<OperationState<void>, void>
Parameters
- jobScheduleId
-
string
Returns
PollerLike<OperationState<void>, void>
terminateTask(string, string, TerminateTaskOptionalParams)
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.
function terminateTask(jobId: string, taskId: string, options?: TerminateTaskOptionalParams): Promise<void>
Parameters
- jobId
-
string
- taskId
-
string
- options
- TerminateTaskOptionalParams
Returns
Promise<void>
updateJob(string, BatchJobUpdateOptions, UpdateJobOptionalParams)
This replaces only the Job properties specified in the request. For example, if the Job has constraints, and a request does not specify the constraints element, then the Job keeps the existing constraints.
function updateJob(jobId: string, job: BatchJobUpdateOptions, options?: UpdateJobOptionalParams): Promise<void>
Parameters
- jobId
-
string
- options
- UpdateJobOptionalParams
Returns
Promise<void>
updateJobSchedule(string, BatchJobScheduleUpdateOptions, UpdateJobScheduleOptionalParams)
This replaces only the Job Schedule properties specified in the request. For example, if the schedule property is not specified with this request, then the Batch service will keep the existing schedule. Changes to a Job Schedule only impact Jobs created by the schedule after the update has taken place; currently running Jobs are unaffected.
function updateJobSchedule(jobScheduleId: string, jobSchedule: BatchJobScheduleUpdateOptions, options?: UpdateJobScheduleOptionalParams): Promise<void>
Parameters
- jobScheduleId
-
string
- jobSchedule
- BatchJobScheduleUpdateOptions
- options
- UpdateJobScheduleOptionalParams
Returns
Promise<void>
updatePool(string, BatchPoolUpdateOptions, UpdatePoolOptionalParams)
This only replaces the Pool properties specified in the request. For example, if the Pool has a StartTask associated with it, and a request does not specify a StartTask element, then the Pool keeps the existing StartTask.
function updatePool(poolId: string, pool: BatchPoolUpdateOptions, options?: UpdatePoolOptionalParams): Promise<void>
Parameters
- poolId
-
string
- options
- UpdatePoolOptionalParams
Returns
Promise<void>
uploadNodeLogs(string, string, UploadBatchServiceLogsOptions, UploadNodeLogsOptionalParams)
This is for gathering Azure Batch service log files in an automated fashion from Compute Nodes if you are experiencing an error and wish to escalate to Azure support. The Azure Batch service log files should be shared with Azure support to aid in debugging issues with the Batch service.
function uploadNodeLogs(poolId: string, nodeId: string, uploadOptions: UploadBatchServiceLogsOptions, options?: UploadNodeLogsOptionalParams): Promise<UploadBatchServiceLogsResult>
Parameters
- poolId
-
string
- nodeId
-
string
- uploadOptions
- UploadBatchServiceLogsOptions
- options
- UploadNodeLogsOptionalParams
Returns
Promise<UploadBatchServiceLogsResult>