Merge pull request #30927 from codyhoag/winc-lb-bz-fixed

Removed BZ#1905950 and related info from known issues

Author: codyhoag

modules/windows-machineset-aws.adoc

@@ -80,7 +80,7 @@ $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
 <2> Specify the infrastructure ID, worker label, and zone.
 <3> Configure the machine set as a Windows machine.
 <4> Configure the Windows node as a compute machine.
-<5> Specify the AMI ID of a Windows image with a container runtime installed. You must use Windows Server 2019 with a version 10.0.17763.1457 or earlier.
+<5> Specify the AMI ID of a Windows image with a container runtime installed. You must use Windows Server 2019.
 <6> Specify the AWS zone, like `us-east-1a`.
 <7> Specify the AWS region, like `us-east-1`.
 <8> Created by the WMCO when it is configuring the first Windows machine. After that, the `windows-user-data` is available for all subsequent machine sets to consume.

modules/windows-machineset-azure.adoc

@@ -74,7 +74,7 @@ $ oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster
 <2> Specify the Windows machine set name. Windows machine names on Azure cannot be more than 15 characters long. Therefore, the machine set name cannot be more than 9 characters long, due to the way machine names are generated from it.
 <3> Configure the machine set as a Windows machine.
 <4> Configure the Windows node as a compute machine.
-<5> Specify a `WindowsServer` image offering that defines the `2019-Datacenter-with-Containers` SKU with version `17763.1457.2009030514` or earlier.
+<5> Specify a `WindowsServer` image offering that defines the `2019-Datacenter-with-Containers` SKU.
 <6> Specify the Azure region, like `centralus`.
 <7> Created by the WMCO when it is configuring the first Windows machine. After that, the `windows-user-data` is available for all subsequent machine sets to consume.
 <8> Specify the zone within your region to place machines on. Be sure that your region supports the zone that you specify.

windows_containers/windows-containers-release-notes-2-x.adoc

@@ -37,10 +37,10 @@ The following Windows Server operating systems are supported in this release of
 |Windows Server version
 
 |AWS
-|Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 version 10.0.17763.1457 or earlier
+|Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019
 
 |Azure
-|Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019 version 10.0.17763.1457 or earlier
+|Windows Server Long-Term Servicing Channel (LTSC): Windows Server 2019
 
 |vSphere
 |Windows Server Semi-Annual Channel (SAC): Windows Server 1909 with link:https://support.microsoft.com/en-us/help/4565351/windows-10-update-kb4565351[Microsoft patch KB4565351]
@@ -76,54 +76,4 @@ Windows nodes are now fully integrated with most of the monitoring capabilities
 
 * The Prometheus windows_exporter used by the WMCO currently collects metrics through HTTP, so it is considered unsafe. You must ensure that only trusted users can retrieve metrics from the endpoint. The windows_exporter feature recently added support for HTTPS configuration, but this configuration has not been implemented for WMCO. Support for HTTPS configuration in the WMCO will be added in a future release.
 
-* If you have a cluster with two Windows nodes, and you create a web server deployment with two replicas, each pod lands on a Windows compute node. In this scenario, if you create a `Service` object with type `LoadBalancer`, communication with the load balancer endpoint is not reliable. To mitigate this issue for clusters installed on AWS or Azure, you must use Windows Server 2019 version 10.0.17763.1457 or earlier. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1905950[*BZ#1905950*])
-+
-To pick the correct image for the `MachineSet` object, follow the instructions based on your cloud provider:
-+
---
-*AWS*
-
-. Run the following command to list AWS image info:
-+
-[source,terminal]
-----
-$ aws ec2 describe-images \
-    --filters Name=name,Values=Windows_Server-2019-English-Full-ContainersLatest-2020.09.09
-    --region <region> \// <1>
-    --query 'Images[*].[ImageId]' \
-    --output=json | jq .[0][0]
-----
-<1> Specify the region your cluster is using.
-
-. Find the AMI ID for a supported Windows image.
-
---
-+
---
-*Azure*
-
-. Run the following command to list Azure image info:
-+
-[source,terminal]
-----
-$ az vm image list --all --location <location> \// <1>
-    --publisher MicrosoftWindowsServer \
-    --offer WindowsServer \
-    --sku 2019-Datacenter-with-Containers \
-    --query "[?contains(version, '17763.1457.2009030514')]"
-----
-<1> Specify the location your cluster is using.
-
-. Find a `WindowsServer` image offering that defines the `2019-Datacenter-with-Containers` SKU with version `17763.1457.2009030514` or earlier.
-+
-.Example output
-----
-    "offer": "WindowsServer",
-    "publisher": "MicrosoftWindowsServer",
-    "sku": "2019-Datacenter-with-Containers",
-    "urn": "MicrosoftWindowsServer:WindowsServer:2019-Datacenter-with-Containers:17763.1457.2009030514",
-    "version": "17763.1457.2009030514"
-----
---
-
-* There is currently an issue in Windows Server 2019 versions released after version `10.0.17763.1457` where Windows workloads behind a load balancer are unreachable for clusters installed on AWS and Azure. You must use Windows Server 2019 version `10.0.17763.1457` or earlier to work around this issue; however, these earlier images are no longer available for AWS. This image version unavailability prevents the ability to run Windows workloads behind a load balancer on clusters installed on AWS at this time. See the link:https://github.com/microsoft/Windows-Containers/issues/78[Microsoft Windows Containers issue] for more details.
+* The kube-proxy service terminates unexpectedly after the load balancer is created if you create the load balancer after the Windows pods begin running. To avoid this issue, you must create the load balancer before the Windows pods status transitions to `Running`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1939968[*BZ#1939968*])