diff --git a/windows_containers/windows-containers-release-notes-4-x.adoc b/windows_containers/windows-containers-release-notes-4-x.adoc deleted file mode 100644 index fb41cfa5bc2b..000000000000 --- a/windows_containers/windows-containers-release-notes-4-x.adoc +++ /dev/null @@ -1,74 +0,0 @@ -:_content-type: ASSEMBLY -[id="windows-containers-release-notes-4-x"] -= Windows Container Support for Red Hat OpenShift release notes -include::_attributes/common-attributes.adoc[] -:context: windows-containers-release-notes - -toc::[] - -[id="about-windows-containers"] -== About Windows Container Support for Red Hat OpenShift - -Windows Container Support for Red Hat OpenShift enables running Windows compute nodes in an {product-title} cluster. Running Windows workloads is possible by using the Red Hat Windows Machine Config Operator (WMCO) to install and manage Windows nodes. With Windows nodes available, you can run Windows container workloads in {product-title}. - -The release notes for Red Hat OpenShift for Windows Containers tracks the development of the WMCO, which provides all Windows container workload capabilities in {product-title}. - -[id="getting-support"] -== Getting support - -You must have a subscription to receive support for the Red Hat WMCO. Deploying Windows container workloads in production clusters is not supported without a subscription. If you do not have a subscription, you can use the community WMCO, a distribution that lacks official support. Request support through the link:http://access.redhat.com/[Red Hat Customer Portal]. - -[id="wmco-4-0-0"] -== Release notes for Red Hat Windows Machine Config Operator 4.0.0 - -This release of the WMCO provides bug fixes for running Windows compute nodes in an {product-title} cluster. The components of the WMCO 4.0.0 were released in link:https://access.redhat.com/errata/RHBA-2021:3702[RHBA-2021:3702]. - -[id="wmco-4-0-0-bug-fixes"] -=== Bug fixes - -* Previously, the WMCO used the raw user-provided instance address when creating Bring-Your-Own-Host (BYOH) Windows nodes. This caused BYOH Windows instances to not join an {product-title} cluster. This bug fix ensures user-provided DNS names resolve to valid IPv4 addresses, and that the resolved value is used when creating BYOH Windows instances. Now BYOH instances with differing hostnames and DNS addresses can be configured as Windows Nodes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1995684[**BZ#1995684**]) - -* Previously, the WMCO performed direct comparisons using unresolved instance addresses when identifying instance-to-node associations. This caused BYOH Windows instances configured to join an {product-title} cluster to be removed. This bug fix validates DNS addresses by performing DNS lookups of entries that are added to the `windows-instances` config map. Now the WMCO can properly identify configured instance-to-node relationships, preventing any premature removals of BYOH nodes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2005126[**BZ#2005126**]) - -[id="wmco-4-0-0-known-issues"] -=== Known issues - -* The file system graphs available in the web console do not display for Windows nodes. This issue is caused by changes in the file system queries, which will be fixed in a future release of WMCO. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1930347[*BZ#1930347*]) - -* For clusters installed on VMware vSphere, the WMCO ignored the `Deleting` phase notification event, leaving incorrect node information in the `windows-exporter` metrics endpoint. This resulted in an invalid mapping for the Prometheus metrics endpoint. This bug has been fixed; the WMCO now recognizes the `Deleting` phase notification event and maps the Prometheus metrics endpoint appropriately. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1995341[**BZ#1995341**]) - -* When the `RunAsUser` permission is set in the security context of a Linux-based pod, the projected files have the correct permissions set, including container user ownership. However, when the Windows equivalent `RunAsUsername` permission is set in a Windows pod, the kubelet is prevented from setting correct ownership on the files in the projected volume. This problem can get exacerbated when used in conjunction with a xref:../storage/persistent_storage/persistent-storage-hostpath.adoc#persistent-storage-using-hostpath[hostPath volume] where best practices are not followed. For example, giving a pod access to the `C:\var\lib\kubelet\pods\` folder results in that pod being able to access service account tokens from other pods. -+ -By default, the projected files will have the following ownership, as shown in this example Windows projected volume file: -+ -[source,posh] ----- -Path : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt -Owner : BUILTIN\Administrators -Group : NT AUTHORITY\SYSTEM -Access : NT AUTHORITY\SYSTEM Allow FullControl - BUILTIN\Administrators Allow FullControl - BUILTIN\Users Allow ReadAndExecute, Synchronize -Audit : -Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU) ----- -+ -This indicates all administrator users, like someone with the `ContainerAdministrator` role, have read, write, and execute access, while non-administrator users have read and execute access. -+ -[IMPORTANT] -==== -{product-title} applies the `RunAsUser` security context to all pods irrespective of its operating system. This means Windows pods automatically have the `RunAsUser` permission applied to its security context. -==== -+ -In addition, if a Windows pod is created with a projected volume with the default `RunAsUser` permission set, the pod gets stuck in the `ContainerCreating` phase. -+ -To handle these issues, {product-title} forces the file permission handling in projected service account volumes set in the security context of the pod to not be honored for projected volumes on Windows (link:https://bugzilla.redhat.com/show_bug.cgi?id=1971745[BZ#1971745]). Note that this behavior for Windows pods is how file permission handling used to work for all pod types prior to {product-title} 4.7. - -include::modules/wmco-prerequisites.adoc[leveloffset=+1] - -[IMPORTANT] -==== -Running Windows container workloads is not supported for clusters in a restricted network or disconnected environment. -==== - -Version 4.x of the WMCO is only compatible with {product-title} 4.9. diff --git a/windows_containers/windows-containers-release-notes-5-x.adoc b/windows_containers/windows-containers-release-notes-5-x.adoc new file mode 100644 index 000000000000..da72873aa6c5 --- /dev/null +++ b/windows_containers/windows-containers-release-notes-5-x.adoc @@ -0,0 +1,43 @@ +:_content-type: ASSEMBLY +[id="windows-containers-release-notes-5-x"] += Windows Container Support for Red Hat OpenShift release notes +include::_attributes/common-attributes.adoc[] +:context: windows-containers-release-notes + +toc::[] + +[id="about-windows-containers"] +== About Windows Container Support for Red Hat OpenShift + +Windows Container Support for Red Hat OpenShift enables running Windows compute nodes in an {product-title} cluster. Running Windows workloads is possible by using the Red Hat Windows Machine Config Operator (WMCO) to install and manage Windows nodes. With Windows nodes available, you can run Windows container workloads in {product-title}. + +The release notes for Red Hat OpenShift for Windows Containers tracks the development of the WMCO, which provides all Windows container workload capabilities in {product-title}. + +ifndef::openshift-origin[] +[id="getting-support"] +== Getting support + +Windows Container Support for Red Hat OpenShift is provided and available as an optional, installable component. Windows Container Support for Red Hat OpenShift is not part of the {product-title} subscription, it requires an additional Red Hat subscription and is supported per the link:https://access.redhat.com/support/offerings/production/soc/[Scope of coverage] and link:https://access.redhat.com/support/offerings/production/sla[Service level agreements]. + +You must have this separate subscription to receive support for the Red Hat WMCO. Without this additional Red Hat subscription, deploying Windows container workloads in production clusters is not supported. You can request support through the link:http://access.redhat.com/[Red Hat Customer Portal]. + +For more information, see the Red Hat OpenShift Container Platform Life Cycle Policy document for link:https://access.redhat.com/support/policy/updates/openshift#windows[OpenShift Container Platform for Windows Containers]. + +If you do not have this additional Red Hat subscription, you can use the community WMCO, a distribution that lacks official support. +endif::openshift-origin[] + +[id="wmco-5-0-0"] +== Release notes for Red Hat Windows Machine Config Operator 5.0.0 + +This release of the WMCO provides bug fixes for running Windows compute nodes in an {product-title} cluster. The components of the WMCO 5.0.0 were released in link:https://access.redhat.com/errata/RHSA-2022:0577[RHSA-2022:0577]. + +* Previously, Windows Containers on Windows Nodes could get assigned an incorrect DNS server IP. This caused DNS resolution to fail. This fix removes the hard-coded cluster DNS information and the DNS server IP is now passed as a command-line argument. As a result, Windows Containers on Windows Nodes get assigned a valid DNS Server IP and DNS resolution works for Windows workloads. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1994859[**BZ#1994859**]) + +* Previously, certain commands being run by the WMCO against Windows VMs that used PowerShell as the default SSH shell were not parsed correctly. As a result, these VMs could not be added to a cluster as a node. With this fix the WMCO identifies the default SSH shell of a VM and runs commands accordingly. As a result, VMs with PowerShell as the default SSH shell can now be added to the cluster as a node. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2000772[**BZ#2000772**]) + +* Previously, if a Bring-Your-Own-Host (BYOH) VM was specified with a DNS object, the WMCO was not properly associating the VM with its node object. This caused the WMCO to attempt to configure VMs that were already fully configured. With this fix the WMCO correctly resolves the DNS address of the VMs when looking for an associated node. As a result, BYOH VMs are now only configured when needed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2005360[**BZ#2005360**]) + +* Previously, if the `windows-exporter` metrics endpoint object contained a reference to a deleted machine, the WMCO ignored `Deleting` phase notification event for those machines. This fix removes the validation of the machine object from event filtering. As a result, the `windows-exporter` metrics endpoint object is correctly updated even when the machine is still deleting. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2008601[**BZ#2008601**]) + +* Previously, if an entity other than the WMCO modified the certificate signing request (CSR) associated with a BYOH node, the WMCO would have a stale reference to the CSR and would be unable to approve it. With this fix, if an update conflict is detected, the WMCO retries the CSR approval until a specified timeout. As a result, the CSR processing completes as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2032048[**BZ#2032048**]) +