Merge branch 'main' of https://github.com/microsoftdocs/azure-docs-pr

Author: ggailey777

articles/api-center/enable-managed-api-analysis-linting.md

@@ -3,7 +3,7 @@ title: Managed API linting and analysis - Azure API Center
 description: Enable managed linting of API definitions in your API center to analyze compliance of APIs with the organization's API style guide.
 ms.service: azure-api-center
 ms.topic: how-to
-ms.date: 08/23/2024
+ms.date: 11/01/2024
 ms.author: danlep
 author: dlepow
 ms.custom: 
@@ -30,9 +30,7 @@ In this scenario:
 * Currently, only OpenAPI specification documents in JSON or YAML format are analyzed.
 * By default, you enable analysis with the [`spectral:oas` ruleset](https://docs.stoplight.io/docs/spectral/4dec24461f3af-open-api-rules). To learn more about the built-in rules, see the [Spectral GitHub repo](https://github.com/stoplightio/spectral/blob/develop/docs/reference/openapi-rules.md). 
 * Currently, you configure a single ruleset, and it's applied to all OpenAPI definitions in your API center.
-* The following are limits for maximum number of API definitions linted per 4 hours:
-    * Free tier: 10
-    * Standard tier: 100
+* There are [limits](../azure-resource-manager/management/azure-subscription-service-limits.md?toc=/azure/api-center/toc.json&bc=/azure/api-center/breadcrumb/toc.json#api-center-limits) for the maximum number of API definitions analyzed. Analysis can take a few minutes to up to 24 hours to complete.
 
 ## Prerequisites
 

articles/api-center/includes/api-center-service-limits.md

@@ -7,7 +7,7 @@ author: dlepow
 
 ms.service: azure-api-center
 ms.topic: include
-ms.date: 10/18/2024
+ms.date: 11/07/2024
 ms.author: danlep
 ms.custom: Include file
 ---
@@ -20,14 +20,16 @@ ms.custom: Include file
 | Maximum number of deployments per API | 10 | 10 |
 | Maximum number of environments | 20 | 20 |
 | Maximum number of workspaces  | 1 (Default) | 1 (Default) |
-| Maximum number of custom metadata properties per entity<sup>4</sup> | 10 | 20 |
+| Maximum number of custom metadata properties per entity<sup>3</sup> | 10 | 20 |
 | Maximum number of child properties in custom metadata property of type "object" | 10 |10 | 
 | Maximum requests per minute (data plane) | 3,000 | 6,000  |
-| Maximum number of API definitions [linted](../enable-managed-api-analysis-linting.md) per 4 hours | 10 | 100  |
+| Maximum number of APIs accessed through data plane API | 5 | 10,000 |
+| Maximum number of API definitions [analyzed](../enable-managed-api-analysis-linting.md) | 10 | 2,000<sup>4</sup>  |
 | Maximum number of linked API sources<sup>5</sup> | 1  |  3 |
+| Maximum number of APIs synchronized from a linked API source | 200 | 2,000<sup>4</sup>  |
 
-<sup>1</sup> Free plan provided for 90 days, then service is soft-deleted.<br/>
+<sup>1</sup> Free plan provided for 90 days, then service is soft-deleted. Use of full service features including API analysis and access through the data plane API is limited.<br/>
 <sup>2</sup> To increase a limit in the Standard plan, contact [support](https://azure.microsoft.com/support/options/).<br/>
-<sup>3</sup> In the Free plan, use of full service features including API analysis and access through the data plane API is limited to 5 APIs.<br/>
-<sup>4</sup> Custom metadata properties assigned to APIs, deployments, and environments.<br/>
-<sup>5</sup> Sources such as linked API Management instances. In the Free plan, synchronization from a linked API source is limited to 200 APIs and 5 API definitions.
+<sup>3</sup> Custom metadata properties assigned to APIs, deployments, and environments.<br/>
+<sup>4</sup> Process can take a few minutes to up to 24 hours to complete.<br/> 
+<sup>5</sup> Sources such as linked API Management instances. 

articles/api-center/synchronize-api-management-apis.md

@@ -27,8 +27,8 @@ When you link an API Management instance as an API source, the following happens
 API Management APIs automatically synchronize to the API center whenever existing APIs' settings change (for example, new versions are added), new APIs are created, or APIs are deleted. This synchronization is one-way from API Management to your Azure API center, meaning API updates in the API center aren't synchronized back to the API Management instance.
 
 > [!NOTE]
-> * API updates in API Management can take a few minutes to synchronize to your API center.
 > * There are [limits](../azure-resource-manager/management/azure-subscription-service-limits.md?toc=/azure/api-center/toc.json&bc=/azure/api-center/breadcrumb/toc.json#api-center-limits) for the number of linked API Management instances (API sources).
+> * API updates in API Management can take a few minutes to up to 24 hours to synchronize to your API center.
 
 ### Entities synchronized from API Management
 

articles/app-service/environment/ase-multi-tenant-comparison.md

@@ -74,7 +74,7 @@ App Service Environment v3 tends to be more expensive than the public multitenan
 |Pricing     |[Pay per instance](overview.md#pricing)|[Pay per instance](../../app-service/overview-hosting-plans.md)|
 |Reserved instances|[Available](overview.md#pricing)|[Available](../../app-service/overview-hosting-plans.md)|
 |Savings plans|[Available](overview.md#pricing)|[Available](../../app-service/overview-hosting-plans.md)|
-|Availability zone pricing|[There's a minimum charge of 18 cores.](overview.md#pricing) There's no added charge for availability zone support if you have 18 or more cores across your App Service plan instances. If you have fewer than 18 cores across your App Service plans in the zone redundant App Service Environment, the difference between 18 cores and the sum of the cores from the running instance count is charged as Windows I1v2 instances.|[Three instance minimum enforced per App Service plan](../../reliability/reliability-app-service.md#pricing).|
+|Availability zone pricing|[There's a minimum charge of 18 cores.](overview.md#pricing) There's no added charge for availability zone support if you have 18 or more cores across your App Service plan instances. If you have fewer than 18 cores across your App Service plans in the zone redundant App Service Environment, the difference between 18 cores and the sum of the cores from the running instance count is charged as Windows I1v2 instances.|[Three instance minimum enforced per App Service plan](../../reliability/reliability-app-service.md#cost).|
 
 ### Frequently asked questions
 

articles/app-service/network-secure-outbound-traffic-azure-firewall.md

@@ -99,7 +99,7 @@ Outbound traffic from your app is now routed through the integrated virtual netw
 1. Navigate to the firewall's overview page and select its firewall policy.
 
 1. In the firewall policy page, from the left navigation, select **Application Rules** > **Add a rule collection**.
-1. In **Rules**, add a network rule with the App Service subnet as the source address, and specify an FQDN destination. In the screenshot below, the destination FQDN is set to `api.my-ip.io`.
+1. In **Rules**, add a network rule with the App Service subnet as the source address, and specify an FQDN destination. In the screenshot below, the destination FQDN is set to `contoso.com`.
 
     :::image type="content" source="./media/network-secure-outbound-traffic-azure-firewall/config-azfw-policy-app-rule.png" alt-text="Screenshot of configure Azure Firewall policy rule.":::
 
@@ -113,7 +113,7 @@ Outbound traffic from your app is now routed through the integrated virtual netw
 An easy way to verify your configuration is to use the `curl` command from your app's SCM debug console to verify the outbound connection.
 
 1. In a browser, navigate to `https://<app-name>.scm.azurewebsites.net/DebugConsole`.
-1. In the console, run `curl -s <protocol>://<fqdn-address>` with a URL that matches the application rule you configured, To continue example in the previous screenshot, you can use **curl -s https://api.my-ip.io/ip**. The following screenshot shows a successful response from the API, showing the public IP address of your App Service app.
+1. In the console, run `curl -s <protocol>://<fqdn-address>` with a URL that matches an application rule you configured. The following screenshot is an example to a website that shows a successful response from a API, showing an IP address.
 
     :::image type="content" source="./media/network-secure-outbound-traffic-azure-firewall/verify-outbound-traffic-fw-allow-rule.png" alt-text="Screenshot of verifying the success outbound traffic by using curl command in SCM debug console.":::
 

articles/app-service/overview-vnet-integration.md

@@ -76,6 +76,12 @@ Because subnet size can't be changed after assignment, use a subnet that's large
 
 With multi plan subnet join (MPSJ), you can join multiple App Service plans in to the same subnet. All App Service plans must be in the same subscription but the virtual network/subnet can be in a different subscription. Each instance from each App Service plan requires an IP address from the subnet and to use MPSJ a minimum size of `/26` subnet is required. If you plan to join many and/or large scale plans, you should plan for larger subnet ranges.
 
+> [!IMPORTANT]
+> Due to a known bug, MPSJ fails if multiple sites are created and attempt to integrate with the virtual network at the same time. A fix will be deployed soon. In the meantime, you can work around the issue with either of the following methods:
+> * If you create sites manually, create and integrate the sites one by one.
+> * If you create sites programmatically, for example using Terraform or ARM templates, add a [dependsOn](/azure/azure-resource-manager/templates/resource-dependency#dependson) element to each site in your templates to depend on the creation of the previous site for all but the first site in the template. This creates a delay between the site creation and the virtual network integration for each site and therefore isn't blocked by the known bug. For more information see, [Define the order for deploying resources in ARM templates](/azure/azure-resource-manager/templates/resource-dependency).
+>
+
 ### Windows Containers specific limits
 
 Windows Containers uses an extra IP address per app for each App Service plan instance, and you need to size the subnet accordingly. If you have, for example, 10 Windows Container App Service plan instances with four apps running, you need 50 IP addresses and extra addresses to support horizontal (in/out) scale.

articles/application-gateway/for-containers/alb-controller-release-notes.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: greglin
 ms.service: azure-appgw-for-containers
 ms.topic: release-notes
-ms.date: 5/9/2024
+ms.date: 11/7/2024
 ms.author: greglin
 ---
 
@@ -26,12 +26,13 @@ Instructions for new or existing deployments of ALB Controller are found in the
 
 | ALB Controller Version | Gateway API Version | Kubernetes Version | Release Notes |
 | ---------------------- | ------------------- | ------------------ | ------------- |
-| 1.2.3| v1.1 | v1.26, v1.27, v1.28, v1.29, v1.30 | Gateway API v1.1, gRPC support, frontend mutual authentication, readiness probe fixes, custom health probe port and TLS mode  |
+| 1.3.7| v1.1 | v1.26, v1.27, v1.28, v1.29, v1.30 | Minor fixes and improvements |
 
 ## Release history
 
 | ALB Controller Version | Gateway API Version | Kubernetes Version | Release Notes |
 | ---------------------- | ------------------- | ------------------ | ------------- |
+| 1.2.3| v1.1 | v1.26, v1.27, v1.28, v1.29, v1.30 | Gateway API v1.1, gRPC support, frontend mutual authentication, readiness probe fixes, custom health probe port and TLS mode  |
 | 1.0.2| v1 | v1.26, v1.27, v1.28, v1.29 | ECDSA + RSA certificate support for both Ingress and Gateway API, Ingress fixes, Server-sent events support |
 | 1.0.0| v1 | v1.26, v1.27, v1.28 | General Availability! URL redirect for both Gateway and Ingress API, v1beta1 -> v1 of Gateway API, quality improvements<br/>Breaking Changes: TLS Policy for Gateway API [PolicyTargetReference](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1alpha2.PolicyTargetReferenceWithSectionName)<br/>Listener is now referred to as [SectionName](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.SectionName)<br/>Fixes: Request timeout of 3 seconds, [HealthCheckPolicy interval](https://github.com/Azure/AKS/issues/4086), [pod crash for missing API fields](https://github.com/Azure/AKS/issues/4087) |
 | 0.6.3 | v1beta1 | v1.25 | Hotfix to address handling of Application Gateway for Containers frontends during controller restart in managed scenario |

articles/application-gateway/for-containers/examples/http-scenario/deployment.yaml

@@ -0,0 +1,103 @@
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: test-infra
+---
+
+apiVersion: v1
+kind: Service
+metadata:
+  name: backend-v1
+  namespace: test-infra
+spec:
+  selector:
+    app: backend-v1
+  ports:
+    - protocol: TCP
+      port: 8080
+      targetPort: 3000
+---
+
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: backend-v1
+  namespace: test-infra
+  labels:
+    app: backend-v1
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: backend-v1
+  template:
+    metadata:
+      labels:
+        app: backend-v1
+    spec:
+      containers:
+      - name: backend-v1
+        image: gcr.io/k8s-staging-ingressconformance/echoserver:v20221109-7ee2f3e
+        lifecycle:
+          preStop:
+            exec:
+              command: ["sleep", "10"]
+        env:
+        - name: POD_NAME
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.name
+        - name: NAMESPACE
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.namespace
+        resources:
+          requests:
+            cpu: 10m
+---
+
+apiVersion: v1
+kind: Service
+metadata:
+  name: backend-v2
+  namespace: test-infra
+spec:
+  selector:
+    app: backend-v2
+  ports:
+    - protocol: TCP
+      port: 8080
+      targetPort: 3000
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: backend-v2
+  namespace: test-infra
+  labels:
+    app: backend-v2
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: backend-v2
+  template:
+    metadata:
+      labels:
+        app: backend-v2
+    spec:
+      containers:
+      - name: backend-v2
+        image: gcr.io/k8s-staging-ingressconformance/echoserver:v20221109-7ee2f3e
+        env:
+        - name: POD_NAME
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.name
+        - name: NAMESPACE
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.namespace
+        resources:
+          requests:
+            cpu: 10m