Azure.Compute.Batch Namespace

A locality hint that can be used by the Batch service to select a Compute Node on which to start a Task.

The settings for an authentication token that the Task can use to perform Batch service operations.

The configuration parameters used for performing automatic OS upgrade.

The results and errors from an execution of a Pool autoscale formula.

An error that occurred when executing or evaluating a Pool autoscale formula.

Specifies the options for the auto user that runs an Azure Batch Task.

Information used to connect to an Azure Storage Container using Blobfuse.

Information used to connect to an Azure Fileshare.

Contains information about an application in an Azure Batch Account.

A reference to an Package to be deployed to Compute Nodes.

Specifies characteristics for a temporary 'auto pool'. The Batch service will create this auto Pool when the Job is submitted.

The Batch service client.

Client options for BatchClient.

An error response received from the Azure Batch service.

An item of additional information included in an Azure Batch error response.

An error message received in an Azure Batch error response.

Collection of header values that describe Batch File properties

An Azure Batch Job.

The execution constraints for a Job.

Parameters for creating an Azure Batch Job.

Parameters for disabling an Azure Batch Job.

Contains information about the execution of a Job in the Azure Batch service.

Specifies details of a Job Manager Task. The Job Manager Task is automatically started when the Job is created. The Batch service tries to schedule the Job Manager Task before any other Tasks in the Job. When shrinking a Pool, the Batch service tries to preserve Nodes where Job Manager Tasks are running for as long as possible (that is, Compute Nodes running 'normal' Tasks are removed before Compute Nodes running Job Manager Tasks). When a Job Manager Task fails and needs to be restarted, the system tries to schedule it at the highest priority. If there are no idle Compute Nodes available, the system may terminate one of the running Tasks in the Pool and return it to the queue in order to make room for the Job Manager Task to restart. Note that a Job Manager Task in one Job does not have priority over Tasks in other Jobs. Across Jobs, only Job level priorities are observed. For example, if a Job Manager in a priority 0 Job needs to be restarted, it will not displace Tasks of a priority 1 Job. Batch will retry Tasks when a recovery operation is triggered on a Node. Examples of recovery operations include (but are not limited to) when an unhealthy Node is rebooted or a Compute Node disappeared due to host failure. Retries due to recovery operations are independent of and are not counted against the maxTaskRetryCount. Even if the maxTaskRetryCount is 0, an internal retry due to a recovery operation may occur. Because of this, all Tasks should be idempotent. This means Tasks need to tolerate being interrupted and restarted without causing any corruption or duplicate data. The best practice for long running Tasks is to use some form of checkpointing.

The network configuration for the Job.

The status of the Job Preparation and Job Release Tasks on a Compute Node.

A Job Preparation Task to run before any Tasks of the Job on any given Compute Node. You can use Job Preparation to prepare a Node to run Tasks for the Job. Activities commonly performed in Job Preparation include: Downloading common resource files used by all the Tasks in the Job. The Job Preparation Task can download these common resource files to the shared location on the Node. (AZ_BATCH_NODE_ROOT_DIR\shared), or starting a local service on the Node so that all Tasks of that Job can communicate with it. If the Job Preparation Task fails (that is, exhausts its retry count before exiting with exit code 0), Batch will not run Tasks of this Job on the Node. The Compute Node remains ineligible to run Tasks of this Job until it is reimaged. The Compute Node remains active and can be used for other Jobs. The Job Preparation Task can run multiple times on the same Node. Therefore, you should write the Job Preparation Task to handle re-execution. If the Node is rebooted, the Job Preparation Task is run again on the Compute Node before scheduling any other Task of the Job, if rerunOnNodeRebootAfterSuccess is true or if the Job Preparation Task did not previously complete. If the Node is reimaged, the Job Preparation Task is run again before scheduling any Task of the Job. Batch will retry Tasks when a recovery operation is triggered on a Node. Examples of recovery operations include (but are not limited to) when an unhealthy Node is rebooted or a Compute Node disappeared due to host failure. Retries due to recovery operations are independent of and are not counted against the maxTaskRetryCount. Even if the maxTaskRetryCount is 0, an internal retry due to a recovery operation may occur. Because of this, all Tasks should be idempotent. This means Tasks need to tolerate being interrupted and restarted without causing any corruption or duplicate data. The best practice for long running Tasks is to use some form of checkpointing.

Contains information about the execution of a Job Preparation Task on a Compute Node.

A Job Release Task to run on Job completion on any Compute Node where the Job has run. The Job Release Task runs when the Job ends, because of one of the following: The user calls the Terminate Job API, or the Delete Job API while the Job is still active, the Job's maximum wall clock time constraint is reached, and the Job is still active, or the Job's Job Manager Task completed, and the Job is configured to terminate when the Job Manager completes. The Job Release Task runs on each Node where Tasks of the Job have run and the Job Preparation Task ran and completed. If you reimage a Node after it has run the Job Preparation Task, and the Job ends without any further Tasks of the Job running on that Node (and hence the Job Preparation Task does not re-run), then the Job Release Task does not run on that Compute Node. If a Node reboots while the Job Release Task is still running, the Job Release Task runs again when the Compute Node starts up. The Job is not marked as complete until all Job Release Tasks have completed. The Job Release Task runs in the background. It does not occupy a scheduling slot; that is, it does not count towards the taskSlotsPerNode limit specified on the Pool.

Contains information about the execution of a Job Release Task on a Compute Node.

A Job Schedule that allows recurring Jobs by specifying when to run Jobs and a specification used to create each Job.

The schedule according to which Jobs will be created. All times are fixed respective to UTC and are not impacted by daylight saving time.

Parameters for creating an Azure Batch Job Schedule.

Contains information about Jobs that have been and will be run under a Job Schedule.

Resource usage statistics for a Job Schedule.

Parameters for updating an Azure Batch Job Schedule.

An error encountered by the Batch service when scheduling a Job.

Specifies details of the Jobs to be created on a schedule.

Resource usage statistics for a Job.

Parameters for terminating an Azure Batch Job.

Parameters for updating an Azure Batch Job.

A Compute Node in the Batch service.

The Batch Compute Node agent is a program that runs on each Compute Node in the Pool and provides Batch capability on the Compute Node.

The number of Compute Nodes in each Compute Node state.

Parameters for disabling scheduling on an Azure Batch Compute Node.

The endpoint configuration for the Compute Node.

An error encountered by a Compute Node.

Information about a file or directory on a Compute Node.

The reference to a user assigned identity associated with the Batch pool which a compute node will use.

Information about the Compute Node on which a Task ran.

For regional placement, nodes in the pool will be allocated in the same region. For zonal placement, nodes in the pool will be spread across different zones with best effort balancing.

Parameters for rebooting an Azure Batch Compute Node.

The remote login settings for a Compute Node.

Parameters for removing nodes from an Azure Batch Pool.

Parameters for creating a user account for RDP or SSH access on an Azure Batch Compute Node.

Parameters for updating a user account for RDP or SSH access on an Azure Batch Compute Node.

The configuration for virtual machine extension instance view.

A Pool in the Azure Batch service.

Parameters for creating an Azure Batch Pool.

Parameters for enabling automatic scaling on an Azure Batch Pool.

The endpoint configuration for a Pool.

Parameters for evaluating an automatic scaling formula on an Azure Batch Pool.

The identity of the Batch pool, if configured.

Specifies how a Job should be assigned to a Pool.

The number of Compute Nodes in each state for a Pool.

Customizing the Serialization of BatchPoolReplaceContent to handle the missing variable certificateReferences. This is a work around will be removed in the next release

Parameters for changing the size of an Azure Batch Pool.

Statistics related to resource consumption by Compute Nodes in a Pool.

Specification for creating a new Pool.

Contains utilization and resource usage statistics for the lifetime of a Pool.

Parameters for updating an Azure Batch Pool.

Usage metrics for a Pool across an aggregation interval.

Statistics related to Pool usage information.

Batch will retry Tasks when a recovery operation is triggered on a Node. Examples of recovery operations include (but are not limited to) when an unhealthy Node is rebooted or a Compute Node disappeared due to host failure. Retries due to recovery operations are independent of and are not counted against the maxTaskRetryCount. Even if the maxTaskRetryCount is 0, an internal retry due to a recovery operation may occur. Because of this, all Tasks should be idempotent. This means Tasks need to tolerate being interrupted and restarted without causing any corruption or duplicate data. The best practice for long running Tasks is to use some form of checkpointing. In some cases the StartTask may be re-run even though the Compute Node was not rebooted. Special care should be taken to avoid StartTasks which create breakaway process or install/launch services from the StartTask working directory, as this will block Batch from being able to re-run the StartTask.

Information about a StartTask running on a Compute Node.

Information about an Azure Batch subtask.

A reference to the Azure Virtual Machines Marketplace Image and additional information about the Image.

Batch will retry Tasks when a recovery operation is triggered on a Node. Examples of recovery operations include (but are not limited to) when an unhealthy Node is rebooted or a Compute Node disappeared due to host failure. Retries due to recovery operations are independent of and are not counted against the maxTaskRetryCount. Even if the maxTaskRetryCount is 0, an internal retry due to a recovery operation may occur. Because of this, all Tasks should be idempotent. This means Tasks need to tolerate being interrupted and restarted without causing any corruption or duplicate data. The best practice for long running Tasks is to use some form of checkpointing.

The result of adding a collection of Tasks to a Job.

Result for a single Task added as part of an add Task collection operation.

Execution constraints to apply to a Task.

Contains information about the container which a Task is executing.

The container settings for a Task.

The Task counts for a Job.

The Task and TaskSlot counts for a Job.

Parameters for creating an Azure Batch Task.

Specifies any dependencies of a Task. Any Task that is explicitly specified or within a dependency range must complete before the dependant Task will be scheduled.

Information about the execution of a Task.

Information about a Task failure.

A collection of Azure Batch Tasks to add.

The start and end of the range are inclusive. For example, if a range has start 9 and end 12, then it represents Tasks '9', '10', '11' and '12'.

Information about a Task running on a Compute Node.

Specifies how Tasks should be distributed across Compute Nodes.

The TaskSlot counts for a Job.

Resource usage statistics for a Task.

Information used to connect to a CIFS file system.

Model factory for models.

The configuration for container-enabled Pools.

A private container registry.

Settings which will be used by the data disks associated to Compute Nodes in the Pool. When using attached data disks, you need to mount and format the disks from within a VM to use them.

Specifies the ephemeral Disk Settings for the operating system disk used by the compute node (VM).

The disk encryption configuration applied on compute nodes in the pool. Disk encryption configuration is not supported on Linux pool created with Azure Compute Gallery Image.

An environment variable to be set on a Task process.

How the Batch service should respond if a Task exits with a particular exit code.

A range of exit codes and how the Batch service should respond to exit codes within that range.

Specifies how the Batch service should respond when the Task completes.

Specifies how the Batch service responds to a particular exit condition.

The properties of a file on a Compute Node.

An HTTP header name-value pair.

A reference to an Azure Virtual Machines Marketplace Image or a Azure Compute Gallery Image. To get the list of all Azure Marketplace Image references verified by Azure Batch, see the ' List Supported Images ' operation.

An inbound endpoint on a Compute Node.

A inbound NAT Pool that can be used to address specific ports on Compute Nodes in a Batch Pool externally.

The instance view status.

Properties used to create a user Account on a Linux Compute Node.

The managed disk parameters.

The Batch service does not assign any meaning to this metadata; it is solely for the use of user code.

The file system to mount on each node.

Multi-instance Tasks are commonly used to support MPI Tasks. In the MPI case, if any of the subtasks fail (for example due to exiting with a non-zero exit code) the entire multi-instance Task fails. The multi-instance Task is then terminated and retried, up to its retry limit.

Represents a name-value pair.

The network configuration for a Pool.

A network security group rule to apply to an inbound endpoint.

Information used to connect to an NFS file system.

Settings for the operating system disk of the compute node (VM).

On every file uploads, Batch service writes two log files to the compute node, 'fileuploadout.txt' and 'fileuploaderr.txt'. These log files are used to learn more about a specific failure.

Specifies a file upload destination within an Azure blob storage container.

The destination to which a file should be uploaded.

Options for an output file upload operation, including under what conditions to perform the upload.

The public IP Address configuration of the networking configuration of a Pool.

Information about the most recent Job to run under the Job Schedule.

An error that occurred when resizing a Pool.

A single file or multiple files to be downloaded to a Compute Node.

The configuration parameters used while performing a rolling upgrade.

Specifies the security profile settings for the virtual machine or virtual machine scale set.

Specifies the service artifact reference id used to set same image version for all virtual machines in the scale set when using 'latest' image version.

Specifies the security settings like secure boot and vTPM used while creating the virtual machine.

Describes an upgrade policy - automatic, manual, or rolling.

The Azure Batch service log files upload parameters for a Compute Node.

The result of uploading Batch service log files from a specific Compute Node.

Properties used to create a user used to execute Tasks on an Azure Batch Compute Node.

The user assigned Identity.

The definition of the user identity under which the Task is run. Specify either the userName or autoUser property, but not both.

The configuration for Compute Nodes in a Pool based on the Azure Virtual Machines infrastructure.

Info about the current state of the virtual machine.

The configuration for virtual machine extensions.

The vm extension instance view.

Windows operating system settings to apply to the virtual machine.

Properties used to create a user Account on a Windows Compute Node.

AccessScope enums.

AllocationState enums.

AutoUserScope enums.

BatchJobAction enums.

BatchJobPreparationTaskState enums.

BatchJobReleaseTaskState enums.

BatchJobScheduleState enums.

BatchJobState enums.

BatchNodeCommunicationMode enums.

BatchNodeDeallocationOption enums.

BatchNodeDisableSchedulingOption enums.

BatchNodeFillType enums.

BatchNodePlacementPolicyType enums.

BatchNodeRebootOption enums.

BatchNodeState enums.

BatchPoolIdentityType enums.

BatchPoolLifetimeOption enums.

BatchPoolState enums.

BatchStartTaskState enums.

BatchSubtaskState enums.

BatchTaskAddStatus enums.

BatchTaskExecutionResult enums.

BatchTaskState enums.

CachingType enums.

ContainerType enums.

ContainerWorkingDirectory enums.

DependencyAction enums.

AccessDiffDiskPlacementScope enums.

DisableBatchJobOption enums.

DiskEncryptionTarget enums.

DynamicVNetAssignmentScope enums.

ElevationLevel enums.

ErrorCategory enums.

ImageVerificationType enums.

InboundEndpointProtocol enums.

IPAddressProvisioningType enums.

LoginMode enums.

NetworkSecurityGroupRuleAccess enums.

The action the Batch service should take when all Tasks in the Job are in the completed state.

OnTaskFailure enums.

OSType enums.

OutputFileUploadCondition enums.

SchedulingState enums.

Specifies the SecurityType of the virtual machine. It has to be set to any specified value to enable UefiSettings.

Level code.

StorageAccountType enums.

UpgradeMode enums.

The version of the service to use.