Merge pull request #263483 from MicrosoftDocs/main

1/18 11:00 AM IST Publish

Author: Saisang

articles/ai-services/openai/how-to/manage-costs.md

@@ -58,6 +58,14 @@ Enabling capabilities such as sending data to Azure Monitor Logs and alerting in
 
 You can pay for Azure OpenAI Service charges with your Azure Prepayment credit. However, you can't use Azure Prepayment credit to pay for charges for third party products and services including those products and services found in the Azure Marketplace.
 
+### HTTP Error response code and billing status in Azure OpenAI Service
+
+If the service performs processing, you may be charged even if the status code is not successful (not 200).
+For example, a 400 error due to a content filter or input limit, or a 408 error due to a timeout.
+
+If the service doesn't perform processing, you won't be charged.
+For example, a 401 error due to authentication or a 429 error due to exceeding the Rate Limit.
+
 ## Monitor costs
 
 As you use Azure resources with Azure OpenAI, you incur costs. Azure resource usage unit costs vary by time intervals, such as seconds, minutes, hours, and days, or by unit usage, such as bytes and megabytes. As soon as Azure OpenAI use starts, costs can be incurred and you can see the costs in the [cost analysis](../../../cost-management/quick-acm-cost-analysis.md?WT.mc_id=costmanagementcontent_docsacmhorizontal_-inproduct-learn).

articles/ai-services/speech-service/how-to-custom-speech-test-and-train.md

@@ -270,7 +270,7 @@ Use <a href="http://sox.sourceforge.net" target="_blank" rel="noopener">SoX</a>
 
 ### Custom display text formatting data for training
 
-Learn more about [display text formatting with speech to text](./display-text-format.md).
+Learn more about [preparing display text formatting data](./how-to-custom-speech-display-text-format.md) and [display text formatting with speech to text](./display-text-format.md).
 
 Automatic Speech Recognition output display format is critical to downstream tasks and one-size doesn’t fit all. Adding Custom Display Format rules allows users to define their own lexical-to-display format rules to improve the speech recognition service quality on top of Microsoft Azure Custom Speech Service.
 

articles/ai-services/speech-service/includes/release-notes/release-notes-tts.md

@@ -16,6 +16,40 @@ The custom voice API is available for creating and managing [professional](../..
 
 The newly trained voice models now support 48 kHz sample rate, irrespective of the model version. For previously trained voice models, it's necessary to [upgrade the engine version](../../how-to-custom-voice-create-voice.md?tabs=neural#update-engine-version-for-your-voice-model) to at least **2023.11.13.0** version to enhance the sample rate to 48 kHz.
 
+#### Prebuilt neural voice
+- Introducing new multilingual voices for public preview:
+
+| Locale (BCP-47) | Language | Text to speech voices |
+| ----- | ----- | ----- |
+| `de-DE` | German (Germany) | `de-DE-FlorianMultilingualNeural` (Male) |
+| `en-US` | English (United States) | `en-US-AvaMultilingualNeural` (Female) |
+| `en-US` | English (United States) | `en-US-EmmaMultilingualNeural` (Female) |
+| `fr-FR` | French (France) | `fr-FR-RemyMultilingualNeural` (Male) |
+| `en-US` | English (United States) | `en-US-BrianMultilingualNeural` (Male) |
+| `en-US` | English (United States) | `en-US-AndrewMultilingualNeural` (Male) |
+| `fr-FR` | French (France) | `fr-FR-SeraphinaMultilingualNeural` (Female) |
+| `fr-FR` | French (France) | `fr-FR-VivienneMultilingualNeural` (Female) |
+| `zh-CN` | Chinese (Mandarin, Simplified) | `zh-CN-XiaoxiaoMultilingualNeural` (Female) |
+| `zh-CN` | Chinese (Mandarin, Simplified) | `zh-CN-XiaochenMultilingualNeural` (Female) |
+| `zh-CN` | Chinese (Mandarin, Simplified) | `zh-CN-YunyiMultilingualNeural` (Male) |
+
+- Introducing new `zh-CN-XiaoxiaoDialectsNeural` voices for public preview which support several Chinese dialects and accents:
+
+| Voicename | Secondary language | Dialect/Accent |
+| ----- | ----- | ----- |
+| `zh-CN-XiaoxiaoDialectsNeural` | `zh-CN-shaanxi` | Chinese (Zhongyuan Mandarin Shaanxi, Simplified) |
+|  | `zh-CN-sichuan` | Chinese (Southwestern Mandarin, Simplified) |
+|  | `zh-CN-shanxi` | Chinese (Shanxi Accent Mandarin, Simplified) |
+|  | `nan-CN` | Chinese (Southern Min, Simplified) |
+|  | `zh-CN-anhui` | Chinese (Jianghuai Mandarin Anhui, Simplified) |
+|  | `zh-CN-hunan` | Chinese (Hunan Accent Mandarin, Simplified) |
+|  | `zh-CN-gansu` | Chinese (Lanyin Mandarin Gansu, Simplified) |
+|  | `zh-CN-shandong` | Chinese (Jilu Mandarin, Simplified) |
+|  | `zh-CN-henan` | Chinese (Zhongyuan Mandarin Henan, Simplified) |
+|  | `zh-CN-liaoning` | Chinese (Northeastern Mandarin, Simplified) |
+|  | `zh-TW` | Chinese (Taiwanese Mandarin, Traditional) |
+
+
 ### November 2023 release
 
 #### Personal voice

articles/aks/istio-upgrade.md

@@ -12,12 +12,119 @@ This article addresses upgrade experiences for Istio-based service mesh add-on f
 
 ## How Istio components are upgraded
 
-**Minor version:** Currently the Istio add-on only has minor version 1.17 available. Minor version upgrade experiences are planned for when newer versions of Istio (1.18) are introduced.
+### Minor version upgrade
 
-**Patch version:**
+Istio add-on allows upgrading the minor version using [canary upgrade process][istio-canary-upstream]. When an upgrade is initiated, the control plane of the new (canary) revision is deployed alongside the old (stable) revision's control plane. You can then manually roll over data plane workloads while using monitoring tools to track the health of workloads during this process. If you don't observe any issues with the health of your workloads, you can complete the upgrade so that only the new revision remains on the cluster. Else, you can roll back to the previous revision of Istio.
+
+If the cluster is currently using a supported minor version of Istio, upgrades are only allowed one minor version at a time. If the cluster is using an unsupported version of Istio, you must upgrade to the lowest supported minor version of Istio for that Kubernetes version. After that, upgrades can again be done one minor version at a time.
+
+The following example illustrates how to upgrade from revision `asm-1-17` to `asm-1-18`. The steps are the same for all minor upgrades.
+
+1. Use the [az aks mesh get-upgrades](/cli/azure/aks/mesh#az-aks-mesh-get-upgrades) command to check which revisions are available for the cluster as upgrade targets:
+
+    ```bash
+    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER
+    ```
+
+    If you expect to see a newer revision not returned by this command, you may need to upgrade your AKS cluster first so that it's compatible with the newest revision.
+
+1. Initiate a canary upgrade from revision `asm-1-17` to `asm-1-18` using [az aks mesh upgrade start](/cli/azure/aks/mesh#az-aks-mesh-upgrade-start):
+
+    ```bash
+    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-18
+    ```
+
+    A canary upgrade means the 1.18 control plane is deployed alongside the 1.17 control plane. They continue to coexist until you either complete or roll back the upgrade.
+
+1. Verify control plane pods corresponding to both `asm-1-17` and `asm-1-18` exist:
+
+    * Verify `istiod` pods:
+
+        ```bash
+        kubectl get pods -n aks-istio-system
+        ```
+
+        Example output:
+
+        ```
+        NAME                                        READY   STATUS    RESTARTS   AGE
+        istiod-asm-1-17-55fccf84c8-dbzlt            1/1     Running   0          58m
+        istiod-asm-1-17-55fccf84c8-fg8zh            1/1     Running   0          58m
+        istiod-asm-1-18-f85f46bf5-7rwg4             1/1     Running   0          51m
+        istiod-asm-1-18-f85f46bf5-8p9qx             1/1     Running   0          51m
+        ```
+
+    * If ingress is enabled, verify ingress pods:
+
+        ```bash
+        kubectl get pods -n aks-istio-ingress
+        ```
+
+        Example output:
+
+        ```
+        NAME                                                          READY   STATUS    RESTARTS   AGE
+        aks-istio-ingressgateway-external-asm-1-17-58f889f99d-qkvq2   1/1     Running   0          59m
+        aks-istio-ingressgateway-external-asm-1-17-58f889f99d-vhtd5   1/1     Running   0          58m
+        aks-istio-ingressgateway-external-asm-1-18-7466f77bb9-ft9c8   1/1     Running   0          51m
+        aks-istio-ingressgateway-external-asm-1-18-7466f77bb9-wcb6s   1/1     Running   0          51m
+        aks-istio-ingressgateway-internal-asm-1-17-579c5d8d4b-4cc2l   1/1     Running   0          58m
+        aks-istio-ingressgateway-internal-asm-1-17-579c5d8d4b-jjc7m   1/1     Running   0          59m
+        aks-istio-ingressgateway-internal-asm-1-18-757d9b5545-g89s4   1/1     Running   0          51m
+        aks-istio-ingressgateway-internal-asm-1-18-757d9b5545-krq9w   1/1     Running   0          51m
+        ```
+
+        Observe that ingress gateway pods of both revisions are deployed side-by-side. However, the service and its IP remain immutable.
+
+1. Relabel the namespace so that any new pods get the Istio sidecar associated with the new revision and its control plane:
+
+    ```bash
+    kubectl label namespace default istio.io/rev=asm-1-18 --overwrite
+    ```
+
+    Relabeling doesn't affect your workloads until they're restarted.
+
+1. Individually roll over each of your application workloads by restarting them. For example:
+
+    ```bash
+    kubectl rollout restart deployment <deployment name> -n <deployment namespace>
+    ```
+
+1. Check your monitoring tools and dashboards to determine whether your workloads are all running in a healthy state after the restart. Based on the outcome, you have two options:
+
+    * **Complete the canary upgrade**: If you're satisfied that the workloads are all running in a healthy state as expected, you can complete the canary upgrade. This will remove the previous revision's control plane and leave behind the new revision's control plane on the cluster. Run the following command to complete the canary upgrade:
+
+      ```bash
+      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER
+      ```
+
+    * **Rollback the canary upgrade**: In case you observe any issues with the health of your workloads, you can roll back to the previous revision of Istio:
+
+      * Relabel the namespace to the previous revision
+
+          ```bash
+          kubectl label namespace default istio.io/rev=asm-1-17 --overwrite
+          ```
+
+      * Roll back the workloads to use the sidecar corresponding to the previous Istio revision by restarting these workloads again:
+
+          ```bash
+          kubectl rollout restart deployment <deployment name> -n <deployment namespace>
+          ```
+
+      * Roll back the control plane to the previous revision:
+
+          ```
+          az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER
+          ```
+
+> [!NOTE]
+> Manually relabeling namespaces when moving them to a new revision can be tedious and error-prone. [Revision tags](https://istio.io/latest/docs/setup/upgrade/canary/#stable-revision-labels) solve this problem. Revision tags are stable identifiers that point to revisions and can be used to avoid relabeling namespaces. Rather than relabeling the namespace, a mesh operator can simply change the tag to point to a new revision. All namespaces labeled with that tag will be updated at the same time. However, note that you still need to restart the workloads to make sure the correct version of `istio-proxy` sidecars are injected.
+
+### Patch version upgrade
 
 * Istio add-on patch version availability information is published in [AKS weekly release notes][aks-release-notes].
-* Patches are rolled out automatically for istiod and ingress pods as part of these AKS weekly releases.
+* Patches are rolled out automatically for istiod and ingress pods as part of these AKS weekly releases, which respect the `default` [planned maintenance window](./planned-maintenance.md) set up for the cluster.
 * User needs to initiate patches to Istio proxy in their workloads by restarting the pods for reinjection:
   * Check the version of the Istio proxy intended for new or restarted pods. This version is the same as the version of the istiod and Istio ingress pods after they were patched:
 
@@ -66,4 +173,5 @@ This article addresses upgrade experiences for Istio-based service mesh add-on f
     productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.17.0, mcr.microsoft.com/oss/istio/proxyv2:1.17.2-distroless
     ```
 
-[aks-release-notes]: https://github.com/Azure/AKS/releases
+[aks-release-notes]: https://github.com/Azure/AKS/releases
+[istio-canary-upstream]: https://istio.io/latest/docs/setup/upgrade/canary/

articles/api-management/migrate-stv1-to-stv2.md

@@ -6,7 +6,7 @@ author: dlepow
 ms.service: api-management
 ms.custom: devx-track-azurecli
 ms.topic: how-to
-ms.date: 10/18/2023
+ms.date: 01/11/2024
 ms.author: danlep
 ---
 
@@ -52,26 +52,17 @@ API Management platform migration from `stv1` to `stv2` involves updating the un
 
 For an API Management instance that's not deployed in a VNet, migrate your instance using the **Platform migration** blade in the Azure portal, or invoke the Migrate to `stv2` REST API. 
 
-You can choose whether the virtual IP address of API Management will change, or whether the original VIP address is preserved.
+During the migration, the VIP address of your API Management instance will be preserved. 
 
-* **New virtual IP address (recommended)** - If you choose this mode, API requests remain responsive during migration. Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 30 minutes. After migration, you'll need to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address. 
-
-* **Preserve IP address** - If you preserve the VIP address, API requests will be unresponsive for approximately 15 minutes while the IP address is migrated to the new infrastructure. Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 45 minutes. No further configuration is required after migration.
+* API requests will be unresponsive for approximately 15 minutes while the IP address is migrated to the new infrastructure. 
+* Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 45 minutes. 
+* No further configuration is required after migration.
 
 #### [Portal](#tab/portal)
 
 1. In the [Azure portal](https://portal.azure.com), navigate to your API Management instance.
 1. In the left menu, under **Settings**, select **Platform migration**.
-1. On the **Platform migration** page, select one of the two migration options:
-
-    * **New virtual IP address (recommended)**. The VIP address of your API Management instance will change automatically. Your service will have no downtime, but after migration you'll need to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address.
-
-    * **Preserve IP address** - The VIP address of your API Management instance won't change. Your instance will have downtime for up to 15 minutes.
-
-        :::image type="content" source="media/migrate-stv1-to-stv2/platform-migration-portal.png" alt-text="Screenshot of API Management platform migration in the portal.":::
-
-1. Review guidance for the migration process, and prepare your environment. 
-
+1. On the **Platform migration** page, review guidance for the migration process, and prepare your environment. 
 1. After you've completed preparation steps, select **I have read and understand the impact of the migration process.** Select **Migrate**.
 
 #### [Azure CLI](#tab/cli)
@@ -102,22 +93,15 @@ RG_NAME={name of your resource group}
 # Get resource ID of API Management instance
 APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
 
-# Call REST API to migrate to stv2 and change VIP address
-az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "NewIp"}'
-
-# Alternate call to migrate to stv2 and preserve VIP address
-# az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "PreserveIp"}'
+# Call REST API to migrate to stv2 and preserve VIP address
+az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2023-03-01-preview" --body '{"mode": "PreserveIp"}'
 ```
 ---
 
 ### Verify migration
 
 To verify that the migration was successful, when the status changes to `Online`, check the [platform version](compute-infrastructure.md#how-do-i-know-which-platform-hosts-my-api-management-instance) of your API Management instance. After successful migration, the value is `stv2`.
 
-### Update network dependencies
-
-On successful migration, update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address.
-
 ## Scenario 2: Migrate a network-injected API Management instance
 
 Trigger migration of a network-injected API Management instance to the `stv2` platform by updating the existing network configuration to use new network settings (see the following section). After that update completes, as an optional step, you can migrate back to the original VNet and subnet you used.

articles/azure-cache-for-redis/cache-high-availability.md

@@ -120,9 +120,11 @@ Zone-redundant Enterprise and Enterprise Flash tier caches are available in the
 | Canada Central* | North Europe | | | Australia East |
 | Central US* | UK South | | | Central India |
 | East US | West Europe | | | Southeast Asia |
-| East US 2 | | | | |
-| South Central US | | | | |
+| East US 2 | | | | Japan East* |
+| South Central US | | | | East Asia* |
 | West US 2 | | | | |
+| West US 3 | | | | |
+| Brazil South | | | | |
 
 \* Enterprise Flash tier not available in this region.