[AutoPR batch/data-plane] Update documentation of Batch data plane swagger.

azure-batch/azure/batch/batch_service_client.py

@@ -9,7 +9,7 @@
 # regenerated.
 # --------------------------------------------------------------------------
 
-from msrest.service_client import ServiceClient
+from msrest.service_client import SDKClient
 from msrest import Serializer, Deserializer
 from msrestazure import AzureConfiguration
 from .version import VERSION
@@ -52,7 +52,7 @@ def __init__(
         self.credentials = credentials
 
 
-class BatchServiceClient(object):
+class BatchServiceClient(SDKClient):
     """A client for issuing REST requests to the Azure Batch service.
 
     :ivar config: Configuration for client.
@@ -87,7 +87,7 @@ def __init__(
             self, credentials, base_url=None):
 
         self.config = BatchServiceClientConfiguration(credentials, base_url)
-        self._client = ServiceClient(self.config.credentials, self.config)
+        super(BatchServiceClient, self).__init__(self.config.credentials, self.config)
 
         client_models = {k: v for k, v in models.__dict__.items() if isinstance(v, type)}
         self.api_version = '2018-03-01.6.1'

azure-batch/azure/batch/models/cloud_job.py

@@ -99,7 +99,9 @@ class CloudJob(Model):
     :param execution_info: The execution information for the job.
     :type execution_info: ~azure.batch.models.JobExecutionInformation
     :param stats: Resource usage statistics for the entire lifetime of the
-     job.
+     job. The statistics may not be immediately available. The Batch service
+     performs periodic roll-up of statistics. The typical delay is about 30
+     minutes.
     :type stats: ~azure.batch.models.JobStatistics
     """
 

azure-batch/azure/batch/models/cloud_job_py3.py

@@ -99,7 +99,9 @@ class CloudJob(Model):
     :param execution_info: The execution information for the job.
     :type execution_info: ~azure.batch.models.JobExecutionInformation
     :param stats: Resource usage statistics for the entire lifetime of the
-     job.
+     job. The statistics may not be immediately available. The Batch service
+     performs periodic roll-up of statistics. The typical delay is about 30
+     minutes.
     :type stats: ~azure.batch.models.JobStatistics
     """
 

azure-batch/azure/batch/models/cloud_job_schedule.py

@@ -64,6 +64,9 @@ class CloudJobSchedule(Model):
      is solely for the use of user code.
     :type metadata: list[~azure.batch.models.MetadataItem]
     :param stats: The lifetime resource usage statistics for the job schedule.
+     The statistics may not be immediately available. The Batch service
+     performs periodic roll-up of statistics. The typical delay is about 30
+     minutes.
     :type stats: ~azure.batch.models.JobScheduleStatistics
     """
 

azure-batch/azure/batch/models/cloud_job_schedule_py3.py

@@ -64,6 +64,9 @@ class CloudJobSchedule(Model):
      is solely for the use of user code.
     :type metadata: list[~azure.batch.models.MetadataItem]
     :param stats: The lifetime resource usage statistics for the job schedule.
+     The statistics may not be immediately available. The Batch service
+     performs periodic roll-up of statistics. The typical delay is about 30
+     minutes.
     :type stats: ~azure.batch.models.JobScheduleStatistics
     """
 

azure-batch/azure/batch/models/cloud_pool.py

@@ -56,7 +56,7 @@ class CloudPool(Model):
      machines in a pool are the same size. For information about available
      sizes of virtual machines for Cloud Services pools (pools created with
      cloudServiceConfiguration), see Sizes for Cloud Services
-     (http://azure.microsoft.com/documentation/articles/cloud-services-sizes-specs/).
+     (https://azure.microsoft.com/documentation/articles/cloud-services-sizes-specs/).
      Batch supports all Cloud Services VM sizes except ExtraSmall, A1V2 and
      A2V2. For information about available VM sizes for pools using images from
      the Virtual Machines Marketplace (pools created with
@@ -165,7 +165,9 @@ class CloudPool(Model):
      metadata.
     :type metadata: list[~azure.batch.models.MetadataItem]
     :param stats: Utilization and resource usage statistics for the entire
-     lifetime of the pool.
+     lifetime of the pool. The statistics may not be immediately available. The
+     Batch service performs periodic roll-up of statistics. The typical delay
+     is about 30 minutes.
     :type stats: ~azure.batch.models.PoolStatistics
     """
 

azure-batch/azure/batch/models/cloud_pool_py3.py

@@ -56,7 +56,7 @@ class CloudPool(Model):
      machines in a pool are the same size. For information about available
      sizes of virtual machines for Cloud Services pools (pools created with
      cloudServiceConfiguration), see Sizes for Cloud Services
-     (http://azure.microsoft.com/documentation/articles/cloud-services-sizes-specs/).
+     (https://azure.microsoft.com/documentation/articles/cloud-services-sizes-specs/).
      Batch supports all Cloud Services VM sizes except ExtraSmall, A1V2 and
      A2V2. For information about available VM sizes for pools using images from
      the Virtual Machines Marketplace (pools created with
@@ -165,7 +165,9 @@ class CloudPool(Model):
      metadata.
     :type metadata: list[~azure.batch.models.MetadataItem]
     :param stats: Utilization and resource usage statistics for the entire
-     lifetime of the pool.
+     lifetime of the pool. The statistics may not be immediately available. The
+     Batch service performs periodic roll-up of statistics. The typical delay
+     is about 30 minutes.
     :type stats: ~azure.batch.models.PoolStatistics
     """
 

azure-batch/azure/batch/models/cloud_task.py

@@ -15,6 +15,17 @@
 class CloudTask(Model):
     """An Azure Batch task.
 
+    Batch will retry tasks when a recovery operation is triggered on a compute
+    node. Examples of recovery operations include (but are not limited to) when
+    an unhealthy compute 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.
+
     :param id: A string that uniquely identifies the task within the job. The
      ID can contain any combination of alphanumeric characters including
      hyphens and underscores, and cannot contain more than 64 characters.
@@ -59,7 +70,10 @@ class CloudTask(Model):
      take advantage of shell features such as environment variable expansion.
      If you want to take advantage of such features, you should invoke the
      shell in the command line, for example using "cmd /c MyCommand" in Windows
-     or "/bin/sh -c MyCommand" in Linux.
+     or "/bin/sh -c MyCommand" in Linux. If the command line refers to file
+     paths, it should use a relative path (relative to the task working
+     directory), or use the Batch provided environment variable
+     (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables).
     :type command_line: str
     :param container_settings: The settings for the container under which the
      task runs. If the pool that will run this task has containerConfiguration

azure-batch/azure/batch/models/cloud_task_py3.py

@@ -15,6 +15,17 @@
 class CloudTask(Model):
     """An Azure Batch task.
 
+    Batch will retry tasks when a recovery operation is triggered on a compute
+    node. Examples of recovery operations include (but are not limited to) when
+    an unhealthy compute 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.
+
     :param id: A string that uniquely identifies the task within the job. The
      ID can contain any combination of alphanumeric characters including
      hyphens and underscores, and cannot contain more than 64 characters.
@@ -59,7 +70,10 @@ class CloudTask(Model):
      take advantage of shell features such as environment variable expansion.
      If you want to take advantage of such features, you should invoke the
      shell in the command line, for example using "cmd /c MyCommand" in Windows
-     or "/bin/sh -c MyCommand" in Linux.
+     or "/bin/sh -c MyCommand" in Linux. If the command line refers to file
+     paths, it should use a relative path (relative to the task working
+     directory), or use the Batch provided environment variable
+     (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables).
     :type command_line: str
     :param container_settings: The settings for the container under which the
      task runs. If the pool that will run this task has containerConfiguration

azure-batch/azure/batch/models/compute_node.py

@@ -56,7 +56,7 @@ class ComputeNode(Model):
      For information about available sizes of virtual machines for Cloud
      Services pools (pools created with cloudServiceConfiguration), see Sizes
      for Cloud Services
-     (http://azure.microsoft.com/documentation/articles/cloud-services-sizes-specs/).
+     (https://azure.microsoft.com/documentation/articles/cloud-services-sizes-specs/).
      Batch supports all Cloud Services VM sizes except ExtraSmall, A1V2 and
      A2V2. For information about available VM sizes for pools using images from
      the Virtual Machines Marketplace (pools created with

azure-batch/azure/batch/models/compute_node_py3.py

@@ -56,7 +56,7 @@ class ComputeNode(Model):
      For information about available sizes of virtual machines for Cloud
      Services pools (pools created with cloudServiceConfiguration), see Sizes
      for Cloud Services
-     (http://azure.microsoft.com/documentation/articles/cloud-services-sizes-specs/).
+     (https://azure.microsoft.com/documentation/articles/cloud-services-sizes-specs/).
      Batch supports all Cloud Services VM sizes except ExtraSmall, A1V2 and
      A2V2. For information about available VM sizes for pools using images from
      the Virtual Machines Marketplace (pools created with

azure-batch/azure/batch/models/job_manager_task.py

@@ -28,6 +28,16 @@ class JobManagerTask(Model):
     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 compute
+    node. Examples of recovery operations include (but are not limited to) when
+    an unhealthy compute 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.
 
     All required parameters must be populated in order to send to Azure.
 
@@ -45,7 +55,10 @@ class JobManagerTask(Model):
      advantage of shell features such as environment variable expansion. If you
      want to take advantage of such features, you should invoke the shell in
      the command line, for example using "cmd /c MyCommand" in Windows or
-     "/bin/sh -c MyCommand" in Linux.
+     "/bin/sh -c MyCommand" in Linux. If the command line refers to file paths,
+     it should use a relative path (relative to the task working directory), or
+     use the Batch provided environment variable
+     (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables).
     :type command_line: str
     :param container_settings: The settings for the container under which the
      Job Manager task runs. If the pool that will run this task has
@@ -120,7 +133,7 @@ class JobManagerTask(Model):
     :type authentication_token_settings:
      ~azure.batch.models.AuthenticationTokenSettings
     :param allow_low_priority_node: Whether the Job Manager task may run on a
-     low-priority compute node. The default value is false.
+     low-priority compute node. The default value is true.
     :type allow_low_priority_node: bool
     """
 

azure-batch/azure/batch/models/job_manager_task_py3.py

@@ -28,6 +28,16 @@ class JobManagerTask(Model):
     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 compute
+    node. Examples of recovery operations include (but are not limited to) when
+    an unhealthy compute 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.
 
     All required parameters must be populated in order to send to Azure.
 
@@ -45,7 +55,10 @@ class JobManagerTask(Model):
      advantage of shell features such as environment variable expansion. If you
      want to take advantage of such features, you should invoke the shell in
      the command line, for example using "cmd /c MyCommand" in Windows or
-     "/bin/sh -c MyCommand" in Linux.
+     "/bin/sh -c MyCommand" in Linux. If the command line refers to file paths,
+     it should use a relative path (relative to the task working directory), or
+     use the Batch provided environment variable
+     (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables).
     :type command_line: str
     :param container_settings: The settings for the container under which the
      Job Manager task runs. If the pool that will run this task has
@@ -120,7 +133,7 @@ class JobManagerTask(Model):
     :type authentication_token_settings:
      ~azure.batch.models.AuthenticationTokenSettings
     :param allow_low_priority_node: Whether the Job Manager task may run on a
-     low-priority compute node. The default value is false.
+     low-priority compute node. The default value is true.
     :type allow_low_priority_node: bool
     """
 

azure-batch/azure/batch/models/job_preparation_task.py

@@ -32,7 +32,17 @@ class JobPreparationTask(Model):
     run again on the 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 compute node is reimaged, the Job
-    Preparation task is run again before scheduling any task of 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 compute node.
+    Examples of recovery operations include (but are not limited to) when an
+    unhealthy compute 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.
 
     All required parameters must be populated in order to send to Azure.
 
@@ -51,7 +61,10 @@ class JobPreparationTask(Model):
      take advantage of shell features such as environment variable expansion.
      If you want to take advantage of such features, you should invoke the
      shell in the command line, for example using "cmd /c MyCommand" in Windows
-     or "/bin/sh -c MyCommand" in Linux.
+     or "/bin/sh -c MyCommand" in Linux. If the command line refers to file
+     paths, it should use a relative path (relative to the task working
+     directory), or use the Batch provided environment variable
+     (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables).
     :type command_line: str
     :param container_settings: The settings for the container under which the
      Job Preparation task runs. When this is specified, all directories

azure-batch/azure/batch/models/job_preparation_task_py3.py

@@ -32,7 +32,17 @@ class JobPreparationTask(Model):
     run again on the 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 compute node is reimaged, the Job
-    Preparation task is run again before scheduling any task of 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 compute node.
+    Examples of recovery operations include (but are not limited to) when an
+    unhealthy compute 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.
 
     All required parameters must be populated in order to send to Azure.
 
@@ -51,7 +61,10 @@ class JobPreparationTask(Model):
      take advantage of shell features such as environment variable expansion.
      If you want to take advantage of such features, you should invoke the
      shell in the command line, for example using "cmd /c MyCommand" in Windows
-     or "/bin/sh -c MyCommand" in Linux.
+     or "/bin/sh -c MyCommand" in Linux. If the command line refers to file
+     paths, it should use a relative path (relative to the task working
+     directory), or use the Batch provided environment variable
+     (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables).
     :type command_line: str
     :param container_settings: The settings for the container under which the
      Job Preparation task runs. When this is specified, all directories

azure-batch/azure/batch/models/job_release_task.py

@@ -50,7 +50,10 @@ class JobReleaseTask(Model):
      advantage of shell features such as environment variable expansion. If you
      want to take advantage of such features, you should invoke the shell in
      the command line, for example using "cmd /c MyCommand" in Windows or
-     "/bin/sh -c MyCommand" in Linux.
+     "/bin/sh -c MyCommand" in Linux. If the command line refers to file paths,
+     it should use a relative path (relative to the task working directory), or
+     use the Batch provided environment variable
+     (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables).
     :type command_line: str
     :param container_settings: The settings for the container under which the
      Job Release task runs. When this is specified, all directories recursively