Merge branch 'MicrosoftDocs:main' into warning

Author: tejaswikolli-web

articles/ai-services/openai/concepts/models.md

@@ -254,13 +254,18 @@ The following Embeddings models are available with [Azure Government](/azure/azu
 
 ### Assistants (Preview)
 
-For Assistants you need a combination of a supported model and a supported region. Certain tools and capabilities require the latest models. For example, [parallel function calling](../how-to/assistant-functions.md) requires the latest 1106 models.
+For Assistants you need a combination of a supported model, and a supported region. Certain tools and capabilities require the latest models. The following models are available in the Assistants API, SDK, Azure AI Studio and Azure OpenAI Studio..
 
 | Region | `gpt-35-turbo (0613)` | `gpt-35-turbo (1106)` | `gpt-4 (0613)` | `gpt-4 (1106)` | `gpt-4 (0125)` | 
 |-----|---|---|---|---|---|
 | Australia East | ✅ | ✅ | ✅ |✅ | |
-| East US 2 | ✅ | | ✅ |✅ | |
-| Sweden Central | ✅ |✅ |✅ |✅| |
+| East US  | ✅ | | | | ✅ |
+| East US 2 | ✅ |  | ✅ |✅ | |
+| France Central  | ✅ | ✅ |✅ |✅ |  |
+| Norway East | |  | | ✅ |  |
+| Sweden Central  | ✅ |✅ |✅ |✅| |
+| UK South  | ✅ |  ✅ | ✅ |✅ | |
+
 
 For information on Provisioned Throughput Unit (PTU) availability, see [provisioned throughput](./provisioned-throughput.md). 
 

articles/application-gateway/for-containers/application-gateway-for-containers-components.md

@@ -6,13 +6,13 @@ author: greglin
 ms.service: application-gateway
 ms.subservice: appgw-for-containers
 ms.topic: conceptual
-ms.date: 02/27/2024
+ms.date: 03/26/2024
 ms.author: greglin
 ---
 
 # Application Gateway for Containers components
 
-This article provides detailed descriptions and requirements for components of Application Gateway for Containers. Information about how Application Gateway for Containers accepts incoming requests and routes them to a backend target is provided.  For a general overview of Application Gateway for Containers, see [What is Application Gateway for Containers](overview.md).
+This article provides detailed descriptions and requirements for components of Application Gateway for Containers. Information about how Application Gateway for Containers accepts incoming requests and routes them to a backend target is provided. For a general overview of Application Gateway for Containers, see [What is Application Gateway for Containers](overview.md).
 
 ### Core components
 
@@ -25,55 +25,55 @@ This article provides detailed descriptions and requirements for components of A
 
 - An Application Gateway for Containers frontend resource is an Azure child resource of the Application Gateway for Containers parent resource.
 - An Application Gateway for Containers frontend defines the entry point client traffic should be received by a given Application Gateway for Containers.
-  - A frontend can't be associated to multiple Application Gateway for Containers
-  - Each frontend provides a unique FQDN that can be referenced by a customer's CNAME record
-  - Private IP addresses are currently unsupported
-- A single Application Gateway for Containers can support multiple frontends
+  - A frontend can't be associated to multiple Application Gateway for Containers.
+  - Each frontend provides a unique FQDN that can be referenced by a customer's CNAME record.
+  - Private IP addresses are currently unsupported.
+- A single Application Gateway for Containers can support multiple frontends.
 
 ### Application Gateway for Containers associations
 
 - An Application Gateway for Containers association resource is an Azure child resource of the Application Gateway for Containers parent resource.
-- An Application Gateway for Containers association defines a connection point into a virtual network.  An association is a 1:1 mapping of an association resource to an Azure Subnet that has been delegated.
-- Application Gateway for Containers is designed to allow for multiple associations
-  - At this time, the current number of associations is currently limited to 1
-- During creation of an association, the underlying data plane is provisioned and connected to a subnet within the defined virtual network's subnet
+- An Application Gateway for Containers association defines a connection point into a virtual network. An association is a 1:1 mapping of an association resource to an Azure Subnet that has been delegated.
+- Application Gateway for Containers is designed to allow for multiple associations.
+  - At this time, the current number of associations is currently limited to 1.
+- During creation of an association, the underlying data plane is provisioned and connected to a subnet within the defined virtual network's subnet.
 - Each association should assume at least 256 addresses are available in the subnet at time of provisioning.
   - A minimum /24 subnet mask for each deployment (assuming no resources have previously been provisioned in the subnet).
     - If n number of Application Gateway for Containers are provisioned, with the assumption each Application Gateway for Containers contains one association, and the intent is to share the same subnet, the available required addresses should be n*256.
-  - All Application Gateway for Containers association resources should match the same region as the Application Gateway for Containers parent resource
+  - All Application Gateway for Containers association resources should match the same region as the Application Gateway for Containers parent resource.
 
 ### Application Gateway for Containers ALB Controller
 
-- An Application Gateway for Containers ALB Controller is a Kubernetes deployment that orchestrates configuration and deployment of Application Gateway for Containers by watching Kubernetes both Custom Resources and Resource configurations, such as, but not limited to, Ingress, Gateway, and ApplicationLoadBalancer.  It uses both ARM / Application Gateway for Containers configuration APIs to propagate configuration to the Application Gateway for Containers Azure deployment.
-- ALB Controller is deployed / installed via Helm
-- ALB Controller consists of two running pods
-  - alb-controller pod is responsible for orchestrating customer intent to Application Gateway for Containers load balancing configuration
-  - alb-controller-bootstrap pod is responsible for management of CRDs
+- An Application Gateway for Containers ALB Controller is a Kubernetes deployment that orchestrates configuration and deployment of Application Gateway for Containers by watching Kubernetes both Custom Resources and Resource configurations, such as, but not limited to, Ingress, Gateway, and ApplicationLoadBalancer. It uses both ARM / Application Gateway for Containers configuration APIs to propagate configuration to the Application Gateway for Containers Azure deployment.
+- ALB Controller is deployed / installed via Helm.
+- ALB Controller consists of two running pods.
+  - alb-controller pod is responsible for orchestrating customer intent to Application Gateway for Containers load balancing configuration.
+  - alb-controller-bootstrap pod is responsible for management of CRDs.
 
 ## Azure / general concepts
 
 ### Private IP address
 
-- A private IP address isn't explicitly defined as an Azure Resource Manager resource.  A private IP address would refer to a specific host address within a given virtual network's subnet.
+- A private IP address isn't explicitly defined as an Azure Resource Manager resource. A private IP address would refer to a specific host address within a given virtual network's subnet.
 
 ### Subnet delegation
 
 - Microsoft.ServiceNetworking/trafficControllers is the namespace adopted by Application Gateway for Containers and may be delegated to a virtual network's subnet.
 - When delegation occurs, provisioning of Application Gateway for Containers resources doesn't happen, nor is there an exclusive mapping to an Application Gateway for Containers association resource.
-- Any number of subnets can have a subnet delegation that is the same or different to Application Gateway for Containers.  Once defined, no other resources, other than the defined service, can be provisioned into the subnet unless explicitly defined by the service's implementation.
+- Any number of subnets can have a subnet delegation that is the same or different to Application Gateway for Containers. Once defined, no other resources, other than the defined service, can be provisioned into the subnet unless explicitly defined by the service's implementation.
 
 ### User-assigned managed identity
 
 - Managed identities for Azure resources eliminate the need to manage credentials in code.
-- A User Managed Identity is required for each Azure Load Balancer Controller to make changes to Application Gateway for Containers
+- A User Managed Identity is required for each Azure Load Balancer Controller to make changes to Application Gateway for Containers.
 - _AppGw for Containers Configuration Manager_ is a built-in RBAC role that allows ALB Controller to access and configure the Application Gateway for Containers resource.
 
  > [!Note]
 > The _AppGw for Containers Configuration Manager_ role has [data action permissions](../../role-based-access-control/role-definitions.md#control-and-data-actions) that the Owner and Contributor roles do not have. It is critical proper permissions are delegated to prevent issues with ALB Controller making changes to the Application Gateway for Containers service.
 
 ## How Application Gateway for Containers accepts a request
 
-Each Application Gateway for Containers frontend provides a generated Fully Qualified Domain Name managed by Azure.  The FQDN may be used as-is or customers may opt to mask the FQDN with a CNAME record.
+Each Application Gateway for Containers frontend provides a generated Fully Qualified Domain Name managed by Azure. The FQDN may be used as-is or customers may opt to mask the FQDN with a CNAME record.
 
 Before a client sends a request to Application Gateway for Containers, the client resolves a CNAME that points to the frontend's FQDN; or the client may directly resolve the FQDN provided by Application Gateway for Containers by using a DNS server.
 
@@ -85,6 +85,10 @@ A set of routing rules evaluates how the request for that hostname should be ini
 
 ## How Application Gateway for Containers routes a request
 
+### HTTP/2 Requests
+
+Application Gateway for Containers fully supports HTTP/2 protocol for communication from the client to the frontend. Communication from Application Gateway for Containers to the backend target uses the HTTP/1.1 protocol. The HTTP/2 setting is always enabled and can't be changed. If clients prefer to use HTTP/1.1 for their communication to the frontend of Application Gateway for Containers, they may continue to negotiate accordingly.
+
 ### Modifications to the request
 
 Application Gateway for Containers inserts three extra headers to all requests before requests are initiated from Application Gateway for Containers to a backend target:
@@ -93,9 +97,9 @@ Application Gateway for Containers inserts three extra headers to all requests b
 - x-forwarded-proto
 - x-request-id
 
-**x-forwarded-for** is the original requestor's client IP address.  If the request is coming through a proxy, the header value appends the address received, comma delimited.  In example: 1.2.3.4,5.6.7.8; where 1.2.3.4 is the client IP address to the proxy in front of Application Gateway for Containers, and 5.6.7.8 is the address of the proxy forwarding traffic to Application Gateway for Containers.
+**x-forwarded-for** is the original requestor's client IP address. If the request is coming through a proxy, the header value appends the address received, comma delimited. In example: 1.2.3.4,5.6.7.8; where 1.2.3.4 is the client IP address to the proxy in front of Application Gateway for Containers, and 5.6.7.8 is the address of the proxy forwarding traffic to Application Gateway for Containers.
 
-**x-forwarded-proto** returns the protocol received by Application Gateway for Containers from the client.  The value is either http or https.
+**x-forwarded-proto** returns the protocol received by Application Gateway for Containers from the client. The value is either http or https.
 
 **x-request-id** is a unique guid generated by Application Gateway for Containers for each client request and presented in the forwarded request to the backend target. The guid consists of 32 alphanumeric characters, separated by dashes (for example: d23387ab-e629-458a-9c93-6108d374bc75). This guid can be used to correlate a request received by Application Gateway for Containers and initiated to a backend target as defined in access logs.
 

articles/application-gateway/for-containers/overview.md

@@ -7,7 +7,7 @@ ms.custom: references_regions
 ms.service: application-gateway
 ms.subservice: appgw-for-containers
 ms.topic: overview
-ms.date: 03/07/2024
+ms.date: 03/26/2024
 ms.author: greglin
 ---
 
@@ -58,6 +58,7 @@ Application Gateway for Containers supports the following features for traffic m
 - Availability zone resiliency
 - Default and custom health probes
 - Header rewrite
+- HTTP/2
 - HTTPS traffic management:
   - SSL termination
   - End to End SSL
@@ -79,7 +80,7 @@ Application Gateway for Containers supports the following features for traffic m
 
 There are two deployment strategies for management of Application Gateway for Containers:
 
-- **Bring your own (BYO) deployment:** In this deployment strategy, deployment and lifecycle of the Application Gateway for Containers resource, Association and Frontend resource is assumed via Azure portal, CLI, PowerShell, Terraform, etc. and referenced in configuration within Kubernetes.
+- **Bring your own (BYO) deployment:** In this deployment strategy, deployment and lifecycle of the Application Gateway for Containers resource, Association, and Frontend resource is assumed via Azure portal, CLI, PowerShell, Terraform, etc. and referenced in configuration within Kubernetes.
   - **In Gateway API:** Every time you wish to create a new Gateway resource in Kubernetes, a Frontend resource should be provisioned in Azure prior and referenced by the Gateway resource. Deletion of the Frontend resource is responsible by the Azure administrator and isn't deleted when the Gateway resource in Kubernetes is deleted.
 - **Managed by ALB Controller:** In this deployment strategy ALB Controller deployed in Kubernetes is responsible for the lifecycle of the Application Gateway for Containers resource and its sub resources. ALB Controller creates Application Gateway for Containers resource when an ApplicationLoadBalancer custom resource is defined on the cluster and its lifecycle is based on the lifecycle of the custom resource.
   - **In Gateway API:** Every time a Gateway resource is created referencing the ApplicationLoadBalancer resource, ALB Controller provisions a new Frontend resource and manage its lifecycle based on the lifecycle of the Gateway resource.
@@ -111,7 +112,7 @@ Application Gateway for Containers is currently offered in the following regions
 
 ### Implementation of Gateway API
 
-ALB Controller implements version [v1](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1) of the [Gateway API](https://gateway-api.sigs.k8s.io/)
+ALB Controller implements version [v1](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1) of the [Gateway API](https://gateway-api.sigs.k8s.io/).
 
 | Gateway API Resource      | Support | Comments     |
 | ------------------------- | ------- | ------------ |
@@ -122,7 +123,7 @@ ALB Controller implements version [v1](https://gateway-api.sigs.k8s.io/reference
 
 ### Implementation of Ingress API
 
-ALB Controller implements support for [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
+ALB Controller implements support for [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
 
 | Ingress API Resource      | Support | Comments     |
 | ------------------------- | ------- | ------------ |

articles/azure-arc/resource-bridge/overview.md

@@ -10,7 +10,7 @@ ms.custom: references_regions
 
 Azure Arc resource bridge is a Microsoft managed product that is part of the core Azure Arc platform. It is designed to host other Azure Arc services. In this release, the resource bridge supports VM self-servicing and management from Azure, for virtualized Windows and Linux virtual machines hosted in an on-premises environment on Azure Stack HCI ([Azure Arc VM management](/azure-stack/hci/manage/azure-arc-vm-management-overview)), VMware ([Arc-enabled VMware vSphere](../vmware-vsphere/overview.md)), and System Center Virtual Machine Manager ([Arc-enabled SCVMM](../system-center-virtual-machine-manager/overview.md)).
 
-Azure Arc resource bridge is a Kubernetes management cluster installed on the customer’s on-premises infrastructure. The resource bridge is provided credentials to the infrastructure control plane that allows it to apply guest management services on the on-premises resources. Arc resource bridge enables projection of on-premises resources as ARM resources and management from ARM as "Arc-enabled" Azure resources.
+Azure Arc resource bridge is a Kubernetes management cluster installed on the customer’s on-premises infrastructure as an appliance VM (aka Arc appliance). The resource bridge is provided credentials to the infrastructure control plane that allows it to apply guest management services on the on-premises resources. Arc resource bridge enables projection of on-premises resources as ARM resources and management from ARM as "Arc-enabled" Azure resources.
 
 Arc resource bridge delivers the following benefits:
 
@@ -144,6 +144,11 @@ There could be instances where supported versions are not sequential. For exampl
 
 Arc resource bridge typically releases a new version on a monthly cadence, at the end of the month. Delays might occur that could push the release date further out. Regardless of when a new release comes out, if you are within n-3 supported versions (starting with 1.0.15), then your Arc resource bridge version is supported. To stay updated on releases, visit the [Arc resource bridge release notes](https://github.com/Azure/ArcResourceBridge/releases) on GitHub. To learn more about upgrade options, visit [Upgrade Arc resource bridge](upgrade.md).
 
+### Private Link Support
+
+Arc resource bridge does not currently support private link. 
+
+
 ## Next steps
 
 * Learn how [Azure Arc-enabled VMware vSphere extends Azure's governance and management capabilities to VMware vSphere infrastructure](../vmware-vsphere/overview.md).

articles/azure-resource-manager/templates/deploy-to-management-group.md

@@ -2,7 +2,7 @@
 title: Deploy resources to management group
 description: Describes how to deploy resources at the management group scope in an Azure Resource Manager template.
 ms.topic: conceptual
-ms.date: 03/20/2024
+ms.date: 03/26/2024
 ms.custom: devx-track-azurepowershell, devx-track-azurecli, devx-track-arm-template
 ---
 
@@ -130,6 +130,8 @@ When deploying to a management group, you can deploy resources to:
 * resource groups in the management group
 * the tenant for the resource group
 
+[!INCLUDE [Scope transitions](../../../includes/resource-manager-scope-transition.md)]
+
 An [extension resource](scope-extension-resources.md) can be scoped to a target that is different than the deployment target.
 
 The user deploying the template must have access to the specified scope.

articles/azure-resource-manager/templates/deploy-to-resource-group.md

@@ -3,7 +3,7 @@ title: Deploy resources to resource groups
 description: Describes how to deploy resources in an Azure Resource Manager template. It shows how to target more than one resource group.
 ms.topic: conceptual
 ms.custom: devx-track-arm-template
-ms.date: 03/20/2024
+ms.date: 03/26/2024
 ---
 
 # Resource group deployments with ARM templates
@@ -85,6 +85,8 @@ When deploying to a resource group, you can deploy resources to:
 * any subscription in the tenant
 * the tenant for the resource group
 
+[!INCLUDE [Scope transitions](../../../includes/resource-manager-scope-transition.md)]
+
 An [extension resource](scope-extension-resources.md) can be scoped to a target that is different than the deployment target.
 
 The user deploying the template must have access to the specified scope.