Merge pull request #208417 from ggailey777/public-repo

Various commits from the public repo

Author: v-stsavell

articles/azure-functions/functions-deployment-slots.md

@@ -204,6 +204,7 @@ Azure Functions deployment slots have the following considerations:
 - The number of slots available to an app depends on the plan. The Consumption plan is only allowed one deployment slot. Additional slots are available for apps running under other plans. For details, see [Service limits](functions-scale.md#service-limits).
 - Swapping a slot resets keys for apps that have an `AzureWebJobsSecretStorageType` app setting equal to `files`.
 - When slots are enabled, your function app is set to read-only mode in the portal.
+- Use function app names shorter than 32 characters. Names longer than 32 characters are at risk of causing [host ID collisons](storage-considerations.md#host-id-considerations).
 
 ## Next steps
 

articles/azure-functions/functions-recover-storage-account.md

@@ -56,7 +56,7 @@ Your function app must be able to access the storage account. Common issues that
 
 * The storage account firewall is enabled and not configured to allow traffic to and from functions. For more information, see [Configure Azure Storage firewalls and virtual networks](../storage/common/storage-network-security.md?toc=%2fazure%2fstorage%2ffiles%2ftoc.json).
 
-* Verify that the `allowSharedKeyAccess` setting is set to `true` which is its default value. For more information, see [Prevent Shared Key authorization for an Azure Storage account](../storage/common/shared-key-authorization-prevent.md?tabs=portal#verify-that-shared-key-access-is-not-allowed). 
+* Verify that the `allowSharedKeyAccess` setting is set to `true`, which is its default value. For more information, see [Prevent Shared Key authorization for an Azure Storage account](../storage/common/shared-key-authorization-prevent.md?tabs=portal#verify-that-shared-key-access-is-not-allowed). 
 
 ## Daily execution quota is full
 
@@ -87,21 +87,36 @@ You can also use the portal from a computer that's connected to the virtual netw
 
 For more information about inbound rule configuration, see the "Network Security Groups" section of [Networking considerations for an App Service Environment](../app-service/environment/network-info.md#network-security-groups).
 
-## Container image unavailable (Linux)
+## Container errors on Linux
 
-For Linux function apps that run from a container, the "Azure Functions runtime is unreachable" error can occur when the container image being referenced is unavailable or fails to start correctly.
-
-To confirm that the error is caused for this reason:
+For function apps that run on Linux in a container, the `Azure Functions runtime is unreachable` error can occur as a result of problems with the container. Use the following procedure to review the container logs for errors:
 
 1. Navigate to the Kudu endpoint for the function app, which is located at `https://scm.<FUNCTION_APP>.azurewebsites.net`, where `<FUNCTION_APP>` is the name of your app.
 
-1. Download the Docker logs ZIP file and review them locally, or review the docker logs from within Kudu.
+1. Download the Docker logs .zip file and review the contents on your local computer. 
+
+1. Check for any logged errors that indicate that the container is unable to start successfully.
+
+### Container image unavailable
+
+Errors can occur when the container image being referenced is unavailable or fails to start correctly. Check for any logged errors that indicate that the container is unable to start successfully.
+
+You need to correct any errors that prevent the container from starting for the function app run correctly.
+
+When the container image can't be found, you'll see a `manifest unknown` error in the Docker logs. In this case, you can use the Azure CLI commands documented at [How to target Azure Functions runtime versions](set-runtime-version.md?tabs=azurecli#manual-version-updates-on-linux) to change the container image being referenced. If you've deployed a [custom container image](functions-create-function-linux-custom-image.md), you need to fix the image and redeploy the updated version to the referenced registry.
+
+### App container has conflicting ports
+
+Your function app might be in an unresponsive state due to conflicting port assignment upon startup. This can happen in the following cases:
+
+* Your container has separate services running where one or more services are tying to bind to the same port as the function app.
+* You've added an Azure Hybrid Connection that shares the same port value as the function app.
 
-1. Check for any errors in the logs that would indicate that the container is unable to start successfully.
+By default, the container in which your function app runs uses port `:80`. When other services in the same container are also trying to using port `:80`, the function app can fail to start. If your logs show port conflicts, change the default ports.
 
-Any such error would need to be remedied for the function to work correctly.
+## Host ID collision 
 
-When the container image can't be found, you should see a `manifest unknown` error in the Docker logs.  In this case, you can use the Azure CLI commands documented at [How to target Azure Functions runtime versions](set-runtime-version.md?tabs=azurecli) to change the container image being reference. If you've deployed a custom container image, you need to fix the image and redeploy the updated version to the referenced registry.
+Starting with version 3.x of the Functions runtime, [host ID collision](storage-considerations.md#host-id-considerations) are detected and logged as a warning. In version 4.x, an error is logged and the host is stopped. If the runtime can't start for your function app, [review the logs](analyze-telemetry-data.md). If there's a warning or an error about host ID collisions, follow the mitigation steps in [Host ID considerations](storage-considerations.md#host-id-considerations).  
 
 ## Next steps
 

articles/azure-functions/functions-versions.md

@@ -37,12 +37,14 @@ The following table indicates which programming languages are currently supporte
 
 ## <a name="creating-1x-apps"></a>Run on a specific version
 
-By default, function apps created in the Azure portal and by the Azure CLI are set to version 4.x. You can modify this version if needed. You can only downgrade the runtime version to 1.x after you create your function app but before you add any functions. Moving to a later version is allowed even with apps that have existing functions. When your app has existing functions, be aware of any breaking changes between versions before moving to a later runtime version. The following sections detail changes between versions:
+By default, function apps created in the Azure portal and by the Azure CLI are set to version 4.x. You can modify this version if needed. You can only downgrade the runtime version to 1.x after you create your function app but before you add any functions. Moving to a later version is allowed even with apps that have existing functions. When your app has existing functions, be aware of any breaking changes between versions before moving to a later runtime version. The following sections detail breaking changes between versions, including language-specific breaking changes. 
 
 + [Between 3.x and 4.x](#breaking-changes-between-3x-and-4x) 
 + [Between 2.x and 3.x](#breaking-changes-between-2x-and-3x)
 + [Between 1.x and later versions](#migrating-from-1x-to-later-versions)
 
+If you don't see your programming language, go select it from the [top of the page](#top).
+
 Before making a change to the major version of the runtime, you should first test your existing code on the new runtime version. You can verify your app runs correctly after the upgrade by deploying to another function app running on the latest major version. You can also verify your code locally by using the runtime-specific version of the [Azure Functions Core Tools](functions-run-local.md), which includes the Functions runtime. 
 
 Downgrades to v2.x aren't supported. When possible, you should always run your apps on the latest supported version of the Functions runtime. 
@@ -320,7 +322,9 @@ To update your project to Azure Functions 4.x:
 
 ### Breaking changes between 3.x and 4.x
 
-The following are some changes to be aware of before upgrading a 3.x app to 4.x. For a full list, see Azure Functions GitHub issues labeled [*Breaking Change: Approved*](https://github.com/Azure/azure-functions/issues?q=is%3Aissue+label%3A%22Breaking+Change%3A+Approved%22+is%3A%22closed+OR+open%22). More changes are expected during the preview period. Subscribe to [App Service Announcements](https://github.com/Azure/app-service-announcements/issues) for updates.
+The following are key breaking changes to be aware of before upgrading a 3.x app to 4.x, including language-specific breaking changes. For a full list, see Azure Functions GitHub issues labeled [*Breaking Change: Approved*](https://github.com/Azure/azure-functions/issues?q=is%3Aissue+label%3A%22Breaking+Change%3A+Approved%22+is%3A%22closed+OR+open%22). More changes are expected during the preview period. Subscribe to [App Service Announcements](https://github.com/Azure/app-service-announcements/issues) for updates.
+
+If you don't see your programming language, go select it from the [top of the page](#top). 
 
 #### Runtime
 
@@ -376,7 +380,7 @@ Azure Functions version 3.x is highly backwards compatible to version 2.x.  Many
 
 ### Breaking changes between 2.x and 3.x
 
-The following are the language-specific changes to be aware of before upgrading a 2.x app to 3.x.
+The following are the language-specific changes to be aware of before upgrading a 2.x app to 3.x. If you don't see your programming language, go select it from the [top of the page](#top). 
 
 ::: zone pivot="programming-language-csharp"
 The main differences between versions when running .NET class library functions is the .NET Core runtime. Functions version 2.x is designed to run on .NET Core 2.2 and version 3.x is designed to run on .NET Core 3.1.