Merge pull request #276135 from MicrosoftDocs/main

5/23 11:00 AM IST Publish

Author: PhilKang0704

.openpublishing.redirection.json

@@ -4060,7 +4060,7 @@
         },
         {
             "source_path_from_root":"/articles/cosmos-db/high-availability.md",
-            "redirect_url":"/azure/reliability/reliability-cosmos-db-nosql.md",
+            "redirect_url":"/azure/reliability/reliability-cosmos-db-nosql",
             "redirect_document_id":false
         },
         {

articles/ai-services/document-intelligence/concept-id-document.md

@@ -231,6 +231,24 @@ Extract data, including name, birth date, and expiration date, from ID documents
 
 The following are the fields extracted per document type. The Document Intelligence ID model `prebuilt-idDocument` extracts the following fields in the `documents.*.fields`. The json output includes all the extracted text in the documents, words, lines, and styles.
 
+::: moniker-end
+
+::: moniker range="doc-intel-3.1.0"
+
+> [!div class="nextstepaction"]
+> [View samples on GitHub.](https://github.com/Azure-Samples/document-intelligence-code-samples/blob/v3.1(2023-07-31-GA)/Python(v3.1)/Prebuilt_model/sample_analyze_identity_documents.py)
+
+::: moniker-end
+
+::: moniker range="doc-intel-4.0.0"
+
+> [!div class="nextstepaction"]
+> [View samples on GitHub.](https://github.com/Azure-Samples/document-intelligence-code-samples/blob/main/Python(v4.0)/Prebuilt_model/sample_analyze_identity_documents.py)
+
+::: moniker-end
+
+::: moniker range=">=doc-intel-3.0.0"
+
 ### `idDocument.driverLicense`
 
 | Field | Type | Description | Example |

articles/ai-services/document-intelligence/concept-invoice.md

@@ -186,6 +186,21 @@ See how data, including customer information, vendor details, and line items, is
 *See* our [Language Support—prebuilt models](language-support-prebuilt.md) page for a complete list of supported languages.
 
 ## Field extraction
+The Document Intelligence invoice model `prebuilt-invoice` extracts the following fields.
+
+::: moniker range="doc-intel-3.1.0"
+
+> [!div class="nextstepaction"]
+> [View samples on GitHub.](https://github.com/Azure-Samples/document-intelligence-code-samples/blob/v3.1(2023-07-31-GA)/Python(v3.1)/Prebuilt_model/sample_analyze_invoices.py)
+
+::: moniker-end
+
+::: moniker range="doc-intel-4.0.0"
+
+> [!div class="nextstepaction"]
+> [View samples on GitHub.](https://github.com/Azure-Samples/document-intelligence-code-samples/blob/main/Python(v4.0)/Prebuilt_model/sample_analyze_invoices.py)
+
+::: moniker-end
 
 |Name| Type | Description | Standardized output |
 |:-----|:----|:----|:----|

articles/ai-services/document-intelligence/concept-receipt.md

@@ -228,6 +228,24 @@ See how Document Intelligence extracts data, including time and date of transact
  Document Intelligence v3.0 and later versions introduce several new features and capabilities. In addition to thermal receipts, the **Receipt** model supports single-page hotel receipt processing and tax detail extraction for all receipt types.
 
  Document Intelligence v4.0 and later versions introduces support for currency for all price-related fields for thermal and hotel receipts.
+ 
+::: moniker-end
+
+::: moniker range="doc-intel-3.1.0"
+
+> [!div class="nextstepaction"]
+> [View samples on GitHub.](https://github.com/Azure-Samples/document-intelligence-code-samples/blob/v3.1(2023-07-31-GA)/Python(v3.1)/Prebuilt_model/sample_analyze_receipts.py)
+
+::: moniker-end
+
+::: moniker range="doc-intel-4.0.0"
+
+> [!div class="nextstepaction"]
+> [View samples on GitHub.](https://github.com/Azure-Samples/document-intelligence-code-samples/blob/main/Python(v4.0)/Prebuilt_model/sample_analyze_receipts.py)
+
+::: moniker-end
+
+::: moniker range=">=doc-intel-3.0.0"
 
 ### Receipt
 

articles/ai-services/document-intelligence/concept-tax-document.md

@@ -106,6 +106,20 @@ See how data, including customer information, vendor details, and line items, is
 
 The following are the fields extracted from a W-2 tax form in the JSON output response.
 
+::: moniker range="doc-intel-3.1.0"
+
+> [!div class="nextstepaction"]
+> [View samples on GitHub.](https://github.com/Azure-Samples/document-intelligence-code-samples/blob/v3.1(2023-07-31-GA)/Python(v3.1)/Prebuilt_model/sample_analyze_tax_us_w2.py)
+
+::: moniker-end
+
+::: moniker range="doc-intel-4.0.0"
+
+> [!div class="nextstepaction"]
+> [View samples on GitHub.](https://github.com/Azure-Samples/document-intelligence-code-samples/blob/main/Python(v4.0)/Prebuilt_model/sample_analyze_tax_us_w2.py)
+
+::: moniker-end
+
 |Name| Type | Description | Example output |dependents
 |:-----|:----|:----|:---:|
 | `W-2FormVariant`| String | IR W-2 Form variant. This field can have the one of the following values: `W-2`, `W-2AS`, `W-2CM`, `W-2GU`, or `W-2VI`| W-2 |

articles/ai-services/openai/assistants-reference.md

@@ -5,7 +5,7 @@ description: Learn how to use Azure OpenAI's Python & REST API with Assistants.
 manager: nitinme
 ms.service: azure-ai-openai
 ms.topic: conceptual
-ms.date: 02/07/2024
+ms.date: 05/22/2024
 author: mrbullwinkle
 ms.author: mbullwin
 recommendations: false
@@ -34,7 +34,7 @@ Create an assistant with a model and instructions.
 | model| string | Required | Model deployment name of the model to use.|
 | name | string or null | Optional | The name of the assistant. The maximum length is 256 characters.|
 | description| string or null | Optional | The description of the assistant. The maximum length is 512 characters.|
-| instructions | string or null | Optional | The system instructions that the assistant uses. The maximum length is 32768 characters.|
+| instructions | string or null | Optional | The system instructions that the assistant uses. The maximum length is 256,000 characters.|
 | tools | array | Optional | Defaults to []. A list of tools enabled on the assistant. There can be a maximum of 128 tools per assistant. Tools can currently be of types `code_interpreter`, or `function`.|
 | file_ids | array | Optional | Defaults to []. A list of file IDs attached to this assistant. There can be a maximum of 20 files attached to the assistant. Files are ordered by their creation date in ascending order.|
 | metadata | map | Optional | Set of 16 key-value pairs that can be attached to an object. This can be useful for storing additional information about the object in a structured format. Keys can be a maximum of 64 characters long and values can be a maximum of 512 characters long.|

articles/ai-studio/how-to/fine-tune-model-llama.md

@@ -1,7 +1,7 @@
 ---
 title: Fine-tune Llama models in Azure AI Studio
 titleSuffix: Azure AI Studio
-description: Learn how to fine-tune Llama models in Azure AI Studio.
+description: Learn how to fine-tune Meta Llama models in Azure AI Studio.
 manager: scottpolly
 ms.service: azure-ai-studio
 ms.topic: how-to
@@ -13,7 +13,7 @@ author: ssalgadodev
 ms.custom: references_regions, build-2024
 ---
 
-# Fine-tune Llama models in Azure AI Studio
+# Fine-tune Meta Llama models in Azure AI Studio
 
 [!INCLUDE [Feature preview](../includes/feature-preview.md)]
 
@@ -250,9 +250,9 @@ You can delete a fine-tuned model from the fine-tuning model list in [Azure AI S
 
 ## Cost and quotas
 
-### Cost and quota considerations for Llama models fine-tuned as a service
+### Cost and quota considerations for Meta Llama models fine-tuned as a service
 
-Llama models fine-tuned as a service are offered by Meta through the Azure Marketplace and integrated with Azure AI Studio for use. You can find the Azure Marketplace pricing when [deploying](./deploy-models-llama.md) or fine-tuning the models.
+Meta Llama models fine-tuned as a service are offered by Meta through the Azure Marketplace and integrated with Azure AI Studio for use. You can find the Azure Marketplace pricing when [deploying](./deploy-models-llama.md) or fine-tuning the models.
 
 Each time a project subscribes to a given offer from the Azure Marketplace, a new resource is created to track the costs associated with its consumption. The same resource is used to track costs associated with inference and fine-tuning; however, multiple meters are available to track each scenario independently.
 

articles/ai-studio/reference/reference-model-inference-api.md

@@ -43,8 +43,8 @@ Models deployed to [serverless API endpoints](../how-to/deploy-models-serverless
 > [!div class="checklist"]
 > * [Cohere Embed V3](../how-to/deploy-models-cohere-embed.md) family of models
 > * [Cohere Command R](../how-to/deploy-models-cohere-command.md) family of models
-> * [Llama2](../how-to/deploy-models-llama.md) family of models
-> * [Llama3](../how-to/deploy-models-llama.md) family of models
+> * [Meta Llama 2](../how-to/deploy-models-llama.md) family of models
+> * [Meta Llama 3](../how-to/deploy-models-llama.md) family of models
 > * [Mistral-Small](../how-to/deploy-models-mistral.md)
 > * [Mistral-Large](../how-to/deploy-models-mistral.md)
 > * [Phi-3](../how-to/deploy-models-phi-3.md) family of models

articles/ai-studio/toc.yml

@@ -72,11 +72,11 @@ items:
         href: how-to/deploy-models-cohere-command.md
       - name: Deploy Cohere Embed models
         href: how-to/deploy-models-cohere-embed.md
-    - name: Llama models
+    - name: Meta Llama models
       items:
-      - name: Deploy Llama family models
+      - name: Deploy Meta Llama family models
         href: how-to/deploy-models-llama.md
-      - name: Fine-tune Llama family models
+      - name: Fine-tune Meta Llama family models
         href: how-to/fine-tune-model-llama.md
     - name: Deploy JAIS models
       href: how-to/deploy-jais-models.md

articles/aks/auto-upgrade-node-os-image.md

@@ -3,10 +3,10 @@ title: Auto-upgrade Node OS Images
 description: Learn how to choose an upgrade channel that best supports your needs for cluster's node OS security and maintenance. 
 ms.topic: article
 ms.custom: build-2023, devx-track-azurecli
-ms.author: nickoman
-author: nickomang
+ms.author: kaarthis
+author: kaarthis
 ms.subservice: aks-upgrade
-ms.date: 11/22/2023
+ms.date: 05/10/2024
 ---
 
 # Auto-upgrade node OS images
@@ -20,19 +20,19 @@ It's best to use both cluster-level [auto-upgrades][Autoupgrade] and the node OS
 
 ## Channels for node OS image upgrades
 
-The selected channel determines the timing of upgrades. When making changes to node OS auto-upgrade channels, allow up to 24 hours for the changes to take effect. Once you change from one channel to another channel, a reimage will be triggered leading to rolling nodes.
+The selected channel determines the timing of upgrades. When making changes to node OS auto-upgrade channels, allow up to 24 hours for the changes to take effect. Once you change from one channel to another channel, a reimage is triggered leading to rolling nodes.
 
 > [!NOTE]
-> Node OS image auto-upgrade won't affect the cluster's Kubernetes version. It only works for a cluster in a [supported version][supported].
+> Node OS image auto-upgrade won't affect the cluster's Kubernetes version.
 
 The following upgrade channels are available. You're allowed to choose one of these options:
 
 |Channel|Description|OS-specific behavior|
 |---|---|
 | `None`| Your nodes don't have security updates applied automatically. This means you're solely responsible for your security updates.|N/A|
-| `Unmanaged`|OS updates are applied automatically through the OS built-in patching infrastructure. Newly allocated machines are unpatched initially. The OS's infrastructure patches them at some point.|Ubuntu and Azure Linux (CPU node pools) apply security patches through unattended upgrade/dnf-automatic roughly once per day around 06:00 UTC. Windows doesn't automatically apply security patches, so this option behaves equivalently to `None`. You'll need to manage the reboot process by using a tool like [kured][kured].|
-| `SecurityPatch`|This channel is in preview and requires enabling the feature flag `NodeOsUpgradeChannelPreview`. Refer to the prerequisites section for details. AKS regularly updates the node's virtual hard disk (VHD) with patches from the image maintainer labeled "security only." There might be disruptions when the security patches are applied to the nodes. When the patches are applied, the VHD is updated and existing machines are upgraded to that VHD, honoring maintenance windows and surge settings. This option incurs the extra cost of hosting the VHDs in your node resource group. If you use this channel, Linux [unattended upgrades][unattended-upgrades] are disabled by default.|Azure Linux doesn't support this channel on GPU-enabled VMs. `SecurityPatch` works on patch versions that are deprecated, so long as the minor Kubernetes version is still supported.|
-| `NodeImage`|AKS updates the nodes with a newly patched VHD containing security fixes and bug fixes on a weekly cadence. The update to the new VHD is disruptive, following maintenance windows and surge settings. No extra VHD cost is incurred when choosing this option. If you use this channel, Linux [unattended upgrades][unattended-upgrades] are disabled by default. Node image upgrades support patch versions that are deprecated, so long as the minor Kubernetes version is still supported.|
+| `Unmanaged`|OS updates are applied automatically through the OS built-in patching infrastructure. Newly allocated machines are unpatched initially. The OS's infrastructure patches them at some point.|Ubuntu and Azure Linux (CPU node pools) apply security patches through unattended upgrade/dnf-automatic roughly once per day around 06:00 UTC. Windows doesn't automatically apply security patches, so this option behaves equivalently to `None`. You need to manage the reboot process by using a tool like [kured][kured].|
+| `SecurityPatch`|OS security patches, which are AKS-tested, fully managed, and applied with safe deployment practices. AKS regularly updates the node's virtual hard disk (VHD) with patches from the image maintainer labeled "security only." There might be disruptions when the security patches are applied to the nodes, however AKS is limiting disruptions by only reimaging your nodes only when necessary, such as for certain kernel security packages. When the patches are applied, the VHD is updated and existing machines are upgraded to that VHD, honoring maintenance windows and surge settings. If AKS decides reimaging nodes isn't necessary, it patches nodes live without draining pods and performs no VHD update. This option incurs the extra cost of hosting the VHDs in your node resource group. If you use this channel, Linux [unattended upgrades][unattended-upgrades] are disabled by default.|Azure Linux doesn't support this channel on GPU-enabled VMs. `SecurityPatch` works on kubernetes patch versions that are deprecated, so long as the minor Kubernetes version is still supported.|
+| `NodeImage`|AKS updates the nodes with a newly patched VHD containing security fixes and bug fixes on a weekly cadence. The update to the new VHD is disruptive, following maintenance windows and surge settings. No extra VHD cost is incurred when choosing this option. If you use this channel, Linux [unattended upgrades][unattended-upgrades] are disabled by default. Node image upgrades support patch versions that are deprecated, so long as the minor Kubernetes version is still supported. Node images are AKS-tested, fully managed, and applied with safe deployment practices|
 
 ## Set the node OS auto-upgrade channel on a new cluster
 
@@ -100,47 +100,20 @@ The default cadence means there's no planned maintenance window applied.
 |---|---|
 | `Unmanaged`|OS driven security updates. AKS has no control over these updates.|Nightly around 6AM UTC for Ubuntu and Azure Linux. Monthly for Windows.|
 | `SecurityPatch`|AKS-tested, fully managed, and applied with safe deployment practices. For more information, refer to [Increased security and resiliency of Canonical workloads on Azure][Blog].|Weekly.|
-| `NodeImage`|AKS|Weekly.|
+| `NodeImage`|AKS-tested, fully managed, and applied with safe deployment practices. For more real time information on releases, look up [AKS Node Images in Release tracker][release-tracker] |Weekly.|
 
 > [!NOTE]
-> While Windows security updates are released on a monthly basis, using the `Unmanaged` channel will not automatically apply these updates to Windows nodes. If you choose the `Unmanaged` channel, you need to manage the reboot process by using a tool like [kured][kured] in order to properly apply security patches.
+> While Windows security updates are released on a monthly basis, using the `Unmanaged` channel will not automatically apply these updates to Windows nodes. If you choose the `Unmanaged` channel, you need to manage the reboot process for Windows nodes. 
 
-## SecurityPatch channel requirements
 
-To use the `SecurityPatch` channel, your cluster must support these requirements:
-
-* Must be using API version `11-02-preview` or later
-* If using Azure CLI, the `aks-preview` CLI extension version `0.5.166` or later must be installed
-* The `NodeOsUpgradeChannelPreview` feature flag must be enabled on your subscription
-
-### Register NodeOsUpgradeChannelPreview
-
-Register the `NodeOsUpgradeChannelPreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:
-
-```azurecli-interactive
-az feature register --namespace "Microsoft.ContainerService" --name "NodeOsUpgradeChannelPreview"
-```
-
-It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:
-
-```azurecli-interactive
-az feature show --namespace "Microsoft.ContainerService" --name "NodeOsUpgradeChannelPreview"
-```
-
-When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:
-
-```azurecli-interactive
-az provider register --namespace Microsoft.ContainerService
-```
-
-## Node channel known bugs
+## Node channel known limitations
 
 - Currently, when you set the [cluster auto-upgrade channel][Autoupgrade] to `node-image`, it also automatically sets the node OS auto-upgrade channel to `NodeImage`. You can't change node OS auto-upgrade channel value if your cluster auto-upgrade channel is `node-image`. In order to set the node OS auto-upgrade channel value, check the [cluster auto-upgrade channel][Autoupgrade] value isn't `node-image`. 
 
 - The `SecurityPatch` channel isn't supported on Windows OS node pools. 
  
  > [!NOTE]
- > By default, any new cluster created with an API version of `06-01-2023` or later (including 06-02-preview)  will set the node OS auto-upgrade channel value to `NodeImage`. Any existing clusters created with an API version earlier than `06-01-2023` will have the node OS auto-upgrade channel value set to `None` by default.
+ >  Use CLI version 2.61.0 or above for the `SecurityPatch` channel.
 
 
 ## Node OS planned maintenance windows
@@ -174,6 +147,10 @@ To view the status of your node OS auto upgrades, look up [activity logs][monito
 
 On the `Unmanaged` channel, AKS has no control over how and when the security updates are delivered. With `SecurityPatch`, the security updates are fully tested and follow safe deployment practices. `SecurityPatch` also honors maintenance windows. For more details, see [Increased security and resiliency of Canonical workloads on Azure][Blog].
 
+* Does `SecurityPatch` always lead to a reimage of my nodes?
+
+AKS limits reimages to only when absolutely necessary, such as certain kernel packages that may require a reimage to get fully applied. `SecurityPatch` is designed to minimize disruptions as much as possible. If AKS decides reimaging nodes isn't necessary, it will patch nodes live without draining pods and no VHD update is performed in such cases.
+
  * How do I know if a `SecurityPatch` or `NodeImage` upgrade is applied on my node?
 
  Run the following command to obtain node labels:
@@ -219,3 +196,4 @@ For a detailed discussion of upgrade best practices and other considerations, se
 
 <!-- LINKS - external -->
 [Blog]: https://techcommunity.microsoft.com/t5/linux-and-open-source-blog/increased-security-and-resiliency-of-canonical-workloads-on/ba-p/3970623
+