Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into updateFileLin

Author: roygara

articles/aks/supported-kubernetes-versions.md

@@ -12,32 +12,138 @@ ms.author: saudas
 
 # Supported Kubernetes versions in Azure Kubernetes Service (AKS)
 
-The Kubernetes community releases minor versions roughly every three months. These releases include new features and improvements. Patch releases are more frequent (sometimes weekly) and are only intended for critical bug fixes in a minor version. These patch releases include fixes for security vulnerabilities or major bugs impacting a large number of customers and products running in production based on Kubernetes.
+The Kubernetes community releases minor versions roughly every three months. These releases include new features and
+improvements. Patch releases are more frequent (sometimes weekly) and are only intended for critical bug fixes in a
+minor version. These patch releases include fixes for security vulnerabilities or major bugs impacting a large number
+of customers and products running in production based on Kubernetes.
 
-A new Kubernetes minor version is made available in [aks-engine][aks-engine] on day one. The AKS Service Level Objective (SLO) targets releasing the minor version for AKS clusters within 30 days, subject to the stability of the release.
+AKS aims to certify and release new Kubernetes versions within 30 days of an upstream release, subject to the stability
+of the release.
+
+## Kubernetes versions
+
+Kubernetes uses the standard [Semantic Versioning](https://semver.org/) versioning scheme. This means that each version
+of Kubernetes follows this numbering scheme:
+
+```
+[major].[minor].[patch]
+
+Example:
+  1.12.14
+  1.12.15
+  1.13.7
+```
+
+Each number in the version indicates general compatibility with the previous version:
+
+* Major versions change when incompatible API changes or backwards compatibility may be broken.
+* Minor versions change when functionality changes are made that are backwards compatible to the other minor releases.
+* Patch versions change when backwards-compatible bug fixes are made.
+
+In general, users should endeavor to run the latest patch release of the minor version they are running, for example if
+your production cluster is on *1.13.6* and *1.13.7* is the latest available patch version available for the *1.13*
+series, you should upgrade to *1.13.7* as soon as you are able to ensure your cluster is fully patched and supported.
 
 ## Kubernetes version support policy
 
 AKS supports four minor versions of Kubernetes:
 
-- The current minor version that is released upstream (n)
-- Three previous minor versions. Each supported minor version also supports two stable patches.
+* The current minor version that is released in AKS (N)
+* Three previous minor versions. Each supported minor version also supports two stable patches.
+
+This is known as "N-3" - (N (Latest release) - 3 (minor versions)).
+
+For example, if AKS introduces *1.13.x* today, support is provided for the following versions:
+
+New minor version        Supported Version List
+-----------------        ----------------------
+1.13.x                   1.12.a, 1.12.b, 1.11.a, 1.11.b, 1.10.a, 1.10.b
+
+Where "x" and ".a" and ".b" are representative patch versions.
+
+For details on communications regarding version changes and expectations, see "Communications" below.
+
+When a new minor version is introduced, the oldest minor version and patch releases supported are deprecated and
+removed. For example if the current supported version list is:
+
+Supported Version List
+----------------------
+1.12.a, 1.12.b, 1.11.a, 1.11.b, 1.10.a, 1.10.b, 1.9.a, 1.9.b
+
+And AKS releases 1.13.x, this means that the 1.9.x versions (all 1.9 versions) will be removed and out of support.
 
-For example, if AKS introduces *1.13.x* today, support is also provided for *1.12.a* + *1.12.b*, *1.11.c* + *1.11d*, *1.10.e* + *1.10f* (where the lettered patch releases are two latest stable builds).
+> [!NOTE]
+> Please note, that if customers are running an unsupported Kubernetes version, they will be asked to upgrade when
+> requesting support for the cluster. Clusters running unsupported Kubernetes releases are not covered by the
+> [AKS support policies](https://docs.microsoft.com/azure/aks/support-policies).
 
-When a new minor version is introduced, the oldest minor version and patch releases supported are retired. 30 days before the release of the new minor version and upcoming version retirement, an announcement is made through the [Azure update channels][azure-update-channel]. In the example above where *1.13.x* is released, the retired versions are *1.9.g* + *1.9.h*.
 
-When you deploy an AKS cluster in the portal or with the Azure CLI, the cluster is always set to the n-1 minor version and latest patch. For example, if AKS supports *1.13.x*, *1.12.a* + *1.12.b*, *1.11.c* + *1.11d*, *1.10.e* + *1.10f*, the default version for new clusters is *1.11.b*.
+In addition to the above on minor versions, AKS supports the two latest *patch** releases of a given minor version. For
+example, given the following supported versions:
+
+Supported Version List
+----------------------
+1.12.1, 1.12.2, 1.11.4, 1.11.5
+
+If upstream Kubernetes released 1.12.3 and 1.11.6 and AKS releases those patch versions, the oldest patch versions
+are deprecated and removed, and the supported version list becomes:
+
+Supported Version List
+----------------------
+1.12.*2*, 1.12.*3*, 1.11.*5*, 1.11.*6*
+
+### Communications
+
+* For new **minor** versions of Kubernetes
+  * All users are notified of the new version and what version will be removed.
+  * Customers running the version **to be removed** will be notified that they have **60 days** to upgrade to a
+    supported release (e.g. minor version).
+* For new **patch** versions of Kubernetes
+  * All users are notified of the new patch version being released and to upgrade to the latest patch release.
+  * Users have **30 days** to upgrade to a newer, supported patch release. Users have **30 days** to upgrade to
+    a supported patch release before the oldest is removed.
+
+AKS defines "released" as general availability, enabled in all SLO / Quality of Service measurements and
+available in all regions.
+
+> [!NOTE]
+> Customers are notified of Kubernetes version releases and deprecations, when a minor version is
+> deprecated/removed users are given 60 days to upgrade to a supported release. In the case of patch releases,
+> customers are given 30 days to upgrade to a supported release.
+
+Notifications are sent via:
+
+* [AKS Release notes](https://aka.ms/aks/releasenotes)
+* Azure portal Notifications
+* [Azure update channel][azure-update-channel]
+
+### Policy Exceptions
+
+AKS reserves the right to add or remove new/existing versions that have been identified to have one or more critical
+production impacting bugs or security issues without advance notice.
+
+Specific patch releases may be skipped, or rollout accelerated depending on the severity of the bug or security issue.
+
+### Azure portal and CLI default versions
+
+When you deploy an AKS cluster in the portal or with the Azure CLI, the cluster is always set to the N-1 minor version
+and latest patch. For example, if AKS supports *1.13.x*, *1.12.a* + *1.12.b*, *1.11.a* + *1.11.b*, *1.10.a* + *1.10b*,
+the default version for new clusters is *1.12.b*.
+
+AKS defaults to N-1 (minor.latestPatch, eg 1.12.b) to provide customers a known, stable and patched version by default.
 
 ## List currently supported versions
 
-To find out what versions are currently available for your subscription and region, use the [az aks get-versions][az-aks-get-versions] command. The following example lists the available Kubernetes versions for the *EastUS* region:
+To find out what versions are currently available for your subscription and region, use the
+[az aks get-versions][az-aks-get-versions] command. The following example lists the available Kubernetes versions for
+the *EastUS* region:
 
 ```azurecli-interactive
 az aks get-versions --location eastus --output table
 ```
 
-The output is similar to the following example, which shows that Kubernetes version *1.13.5* is the most recent version available:
+The output is similar to the following example, which shows that Kubernetes version *1.13.5* is the most recent version
+available:
 
 ```
 KubernetesVersion    Upgrades
@@ -55,20 +161,30 @@ KubernetesVersion    Upgrades
 
 **What happens when a customer upgrades a Kubernetes cluster with a minor version that is not supported?**
 
-If you are on the *n-4* version, you are out of the SLO. If your upgrade from version n-4 to n-3 succeeds, then you are back in the SLO. For example:
+If you are on the *n-4* version, you are outside of support and will be asked to upgrade. If your upgrade from version
+n-4 to n-3 succeeds, you are now within our support policies. For example:
+
+- If the supported AKS versions are *1.13.x*, *1.12.a* + *1.12.b*, *1.11.c* + *1.11d*, and *1.10.e* + *1.10f* and you
+  are on *1.9.g* or *1.9.h*, you are outside of support.
+- If the upgrade from *1.9.g* or *1.9.h* to *1.10.e* or *1.10.f* succeeds, you are back in the within our support policies.
+
+Upgrades to versions older than *n-4* are not supported. In such cases, we recommend customers create new AKS clusters
+and redeploy their workloads.
 
-- If the supported AKS versions are *1.13.x*, *1.12.a* + *1.12.b*, *1.11.c* + *1.11d*, and *1.10.e* + *1.10f* and you are on *1.9.g* or *1.9.h*, you are out of the SLO.
-- If the upgrade from *1.9.g* or *1.9.h* to *1.10.e* or *1.10.f* succeeds, you are back in the SLO.
+**What does 'Out of Support' mean**
 
-Upgrades to versions older than *n-4* are not supported. In such cases, we recommend customers create new AKS clusters and redeploy their workloads.
+'Outside of Support' means that the version you are running is outside of the supported versions list, and you will be
+asked to upgrade the cluster to a supported version when requesting support. Additionally, AKS does not make any
+runtime or other guarantees for clusters outside of the supported versions list.
 
 **What happens when a customer scales a Kubernetes cluster with a minor version that is not supported?**
 
 For minor versions not supported by AKS, scaling in or out continues to work without any issues.
 
 **Can a customer stay on a Kubernetes version forever?**
 
-Yes. However, if the cluster is not on one of the versions supported by AKS, the cluster is out of the AKS SLO. Azure does not automatically upgrade your cluster or delete it.
+Yes. However, if the cluster is not on one of the versions supported by AKS, the cluster is out of the AKS support
+policies. Azure does not automatically upgrade your cluster or delete it.
 
 **What version does the master support if the agent cluster is not in one of the supported AKS versions?**
 

articles/azure-cache-for-redis/cache-how-to-premium-vnet.md

@@ -127,7 +127,7 @@ There are eight inbound port range requirements. Inbound requests in these range
 
 | Port(s) | Direction | Transport Protocol | Purpose | Local IP | Remote IP |
 | --- | --- | --- | --- | --- | --- |
-| 6379, 6380 |Inbound |TCP |Client communication to Redis, Azure load balancing | (Redis subnet) | (Redis subnet), Virtual Network, Azure Load Balancer |
+| 6379, 6380 |Inbound |TCP |Client communication to Redis, Azure load balancing | (Redis subnet) | (Redis subnet), Virtual Network, Azure Load Balancer <sup>2</sup> |
 | 8443 |Inbound |TCP |Internal communications for Redis | (Redis subnet) |(Redis subnet) |
 | 8500 |Inbound |TCP/UDP |Azure load balancing | (Redis subnet) |Azure Load Balancer |
 | 10221-10231 |Inbound |TCP |Internal communications for Redis | (Redis subnet) |(Redis subnet), Azure Load Balancer |
@@ -136,6 +136,8 @@ There are eight inbound port range requirements. Inbound requests in these range
 | 16001 |Inbound |TCP/UDP |Azure load balancing | (Redis subnet) |Azure Load Balancer |
 | 20226 |Inbound |TCP |Internal communications for Redis | (Redis subnet) |(Redis subnet) |
 
+<sup>2</sup> You can use the Service Tag 'AzureLoadBalancer' (Resource Manager) (or 'AZURE_LOADBALANCER' for classic) for authoring the NSG rules.
+
 #### Additional VNET network connectivity requirements
 
 There are network connectivity requirements for Azure Cache for Redis that may not be initially met in a virtual network. Azure Cache for Redis requires all the following items to function properly when used within a virtual network.

articles/azure-databricks/howto-regional-disaster-recovery.md

@@ -130,45 +130,84 @@ To create your own regional disaster recovery topology, follow these requirement
    Copy and save the following python script to a file, and run it in your Databricks command line. For example, `python scriptname.py`.
 
    ```python
-   from subprocess import call, check_output import json
+   from subprocess import call, check_output
+   import json, os
 
    EXPORT_PROFILE = "primary"
    IMPORT_PROFILE = "secondary"
 
-   # Get all clusters info from old workspace 
-   clusters_out = check_output(["databricks", "clusters", "list", "--profile", EXPORT_PROFILE]) clusters_info_list = clusters_out.splitlines()
+   # Get all clusters info from old workspace
+   clusters_out = check_output(["databricks", "clusters", "list", "--profile", EXPORT_PROFILE])
+   clusters_info_list = clusters_out.splitlines()
+
+   # Create a list of all cluster ids
+   clusters_list = []
+   ##for cluster_info in clusters_info_list: clusters_list.append(cluster_info.split(None, 1)[0])
 
-   # Create a list of all cluster ids 
-   clusters_list = [] for cluster_info in clusters_info_list:   clusters_list.append(cluster_info.split(None, 1)[0])
+   for cluster_info in clusters_info_list: 
+      if cluster_info != '':
+         clusters_list.append(cluster_info.split(None, 1)[0])
 
    # Optionally filter cluster ids out manually, so as to create only required ones in new workspace
 
-   # Create a list of mandatory / optional create request elements 
-   cluster_req_elems = ["num_workers","autoscale","cluster_name","spark_version","spark_conf"," node_type_id","driver_node_type_id","custom_tags","cluster_log_conf","sp ark_env_vars","autotermination_minutes","enable_elastic_disk"]
+   # Create a list of mandatory / optional create request elements
+   cluster_req_elems = ["num_workers","autoscale","cluster_name","spark_version","spark_conf","node_type_id","driver_node_type_id","custom_tags","cluster_log_conf","spark_env_vars","autotermination_minutes","enable_elastic_disk"]
+
+   print(str(len(clusters_list)) + " clusters found in the primary site" )
 
+   print ("---------------------------------------------------------")
    # Try creating all / selected clusters in new workspace with same config as in old one.
-   cluster_old_new_mappings = {} for cluster in clusters_list:   print "Trying to migrate cluster " + cluster
+   cluster_old_new_mappings = {}
+   i = 0
+   for cluster in clusters_list:
+      i += 1
+      print("Checking cluster " + str(i) + "/" + str(len(clusters_list)) + " : " + cluster)
+      cluster_get_out = check_output(["databricks", "clusters", "get", "--cluster-id", cluster, "--profile", EXPORT_PROFILE])
+      print ("Got cluster config from old workspace")
+
+       # Remove extra content from the config, as we need to build create request with allowed elements only
+      cluster_req_json = json.loads(cluster_get_out)
+      cluster_json_keys = cluster_req_json.keys()
+
+      #Don't migrate Job clusters
+      if cluster_req_json['cluster_source'] == u'JOB' : 
+         print ("Skipping this cluster as it is a Job cluster : " + cluster_req_json['cluster_id'] )
+         print ("---------------------------------------------------------")
+         continue
 
-   cluster_get_out = check_output(["databricks", "clusters", "get", "--cluster-id", cluster, "--profile", EXPORT_PROFILE])
-   print "Got cluster config from old workspace"
+      for key in cluster_json_keys:
+         if key not in cluster_req_elems:
+            cluster_req_json.pop(key, None)
 
-   # Remove extra content from the config, as we need to build create request with allowed elements only
-   cluster_req_json = json.loads(cluster_get_out)    
-   cluster_json_keys = cluster_req_json.keys()   
+      # Create the cluster, and store the mapping from old to new cluster ids
 
-   for key in cluster_json_keys:     
-      if key not in cluster_req_elems:       
-         cluster_req_json.pop(key, None)
-  
-   # Create the cluster, and store the mapping from old to new cluster ids
-   cluster_create_out = check_output(["databricks", "clusters", "create", "--json", json.dumps(cluster_req_json), "--profile", IMPORT_PROFILE]) 
-   cluster_create_out_json = json.loads(cluster_create_out)   
-   cluster_old_new_mappings[cluster] = cluster_create_out_json['cluster_id']
+      #Create a temp file to store the current cluster info as JSON
+      strCurrentClusterFile = "tmp_cluster_info.json" 
 
-   print "Sent cluster create request to new workspace successfully"
+      #delete the temp file if exists
+      if os.path.exists(strCurrentClusterFile) : 
+         os.remove(strCurrentClusterFile)
 
-   print "Cluster mappings: " + json.dumps(cluster_old_new_mappings)
-   print "All done"
+      fClusterJSONtmp = open(strCurrentClusterFile,"w+")
+      fClusterJSONtmp.write(json.dumps(cluster_req_json))
+      fClusterJSONtmp.close()
+
+      #cluster_create_out = check_output(["databricks", "clusters", "create", "--json", json.dumps(cluster_req_json), "--profile", IMPORT_PROFILE])
+      cluster_create_out = check_output(["databricks", "clusters", "create", "--json-file", strCurrentClusterFile , "--profile", IMPORT_PROFILE])
+      cluster_create_out_json = json.loads(cluster_create_out)
+      cluster_old_new_mappings[cluster] = cluster_create_out_json['cluster_id']
+
+      print ("Cluster create request sent to secondary site workspace successfully")
+      print ("---------------------------------------------------------")
+
+      #delete the temp file if exists
+      if os.path.exists(strCurrentClusterFile) : 
+         os.remove(strCurrentClusterFile)
+
+   print ("Cluster mappings: " + json.dumps(cluster_old_new_mappings))
+   print ("All done")
+   print ("P.S. : Please note that all the new clusters in your secondary site are being started now!")
+   print ("       If you won't use those new clusters at the moment, please don't forget terminating your new clusters to avoid charges")
    ```
 
 6. **Migrate the jobs configuration**

articles/iot-hub/iot-hub-node-node-schedule-jobs.md

@@ -101,7 +101,7 @@ In this section, you create a Node.js console app that responds to a direct meth
    
         // Respond the cloud app for the direct method
         response.send(200, function(err) {
-            if (!err) {
+            if (err) {
                 console.error('An error occurred when sending a method response:\n' + err.toString());
             } else {
                 console.log('Response to method \'' + request.methodName + '\' sent successfully.');