OSDOCS CQA WINC-1: Windows Workload Management and Basics I by mburke5678 · Pull Request #113245 · openshift/openshift-docs

mburke5678 · 2026-06-12T12:45:32Z

https://redhat.atlassian.net/browse/OSDOCS-16908

Previews
Windows Containers Support -> Disabling Windows container workloads
Windows Containers Support -> Scheduling Windows container workloads
Windows Containers Support -> Windows node updates
Machine management -> Manually scaling a compute machine set -> Scaling a compute machine set manually
Postinstallation configuration -> Cluster tasks -> Scaling a compute machine set manually

Assemblies:
windows-node-upgrades.adoc
scheduling-windows-workloads.adoc
disabling-windows-container-workloads.adoc

openshift-ci-robot · 2026-06-12T12:45:34Z

@mburke5678: No Jira issue with key WINC-1 exists in the tracker at https://redhat.atlassian.net.
Once a valid jira issue is referenced in the title of this pull request, request a refresh with /jira refresh.

Details

In response to this:

https://redhat.atlassian.net/browse/OSDOCS-16908

Previews

Assemblies:
windows-node-upgrades.adoc
scheduling-windows-workloads.adoc
disabling-windows-container-workloads.adoc

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

ocpdocs-previewbot · 2026-06-12T12:53:23Z

🤖 Fri Jun 12 19:46:08 - Prow CI generated the docs preview:

https://113245--ocpdocs-pr.netlify.app/openshift-enterprise/latest/machine_management/manually-scaling-machineset.html
https://113245--ocpdocs-pr.netlify.app/openshift-enterprise/latest/post_installation_configuration/cluster-tasks.html
https://113245--ocpdocs-pr.netlify.app/openshift-enterprise/latest/post_installation_configuration/node-tasks.html
https://113245--ocpdocs-pr.netlify.app/openshift-enterprise/latest/windows_containers/disabling-windows-container-workloads.html
https://113245--ocpdocs-pr.netlify.app/openshift-enterprise/latest/windows_containers/scheduling-windows-workloads.html
https://113245--ocpdocs-pr.netlify.app/openshift-enterprise/latest/windows_containers/windows-node-upgrades.html

openshift-ci-robot · 2026-06-12T13:19:31Z

@mburke5678: No Jira issue with key WINC-1 exists in the tracker at https://redhat.atlassian.net.
Once a valid jira issue is referenced in the title of this pull request, request a refresh with /jira refresh.

Details

In response to this:

https://redhat.atlassian.net/browse/OSDOCS-16908

Previews
Windows Containers Support -> Disabling Windows container workloads
Windows Containers Support -> Scheduling Windows container workloads
Windows Containers Support -> Windows node updates
Machine management -> Manually scaling a compute machine set -> Scaling a compute machine set manually
Postinstallation configuration -> Cluster tasks -> Scaling a compute machine set manually

Assemblies:
windows-node-upgrades.adoc
scheduling-windows-workloads.adoc
disabling-windows-container-workloads.adoc

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

lahinson

@mburke5678 Nice work. I spotted a couple things to check. When you're ready feel free to merge.

lahinson · 2026-06-12T18:45:55Z


-You can delete the namespace that was generated for the Windows Machine Config Operator (WMCO) by default.
+[role="_abstract"]
+If you want to disable the capability to run Windows container workloads, after uninstalling the Windows Machine Config Operator (WMCO), you can delete the namespace that was generated by default for the WMCO.


Suggested change

If you want to disable the capability to run Windows container workloads, after uninstalling the Windows Machine Config Operator (WMCO), you can delete the namespace that was generated by default for the WMCO.

If you want to disable the capability to run Windows container workloads, after you uninstall the Windows Machine Config Operator (WMCO), you can delete the namespace that was generated by default for the WMCO.

lahinson · 2026-06-12T18:52:50Z

 With multiple operating systems, and the ability to run multiple Windows OS variants in the same cluster, you must map your Windows pods to a base Windows OS variant by using a `RuntimeClass` object. For example, if you have multiple Windows nodes running on different Windows Server container versions, the cluster could schedule your Windows pods to an incompatible Windows OS variant. You must have `RuntimeClass` objects configured for each Windows OS variant on your cluster. Using a `RuntimeClass` object is also recommended if you have only one Windows OS variant available in your cluster.

-For more information, see Microsoft's documentation on link:https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/update-containers#host-and-container-version-compatibility[Host and container version compatibility, Microsoft Windows documentation].
+For more information, see "Host and container version compatibility" in the Microsoft Windows documentation.


Suggested change

For more information, see "Host and container version compatibility" in the Microsoft Windows documentation.

For more information, see "Host and container version compatibility" in the Microsoft Windows documentation, which is linked in the "Additional resources" section.

lahinson · 2026-06-12T18:53:37Z


-{product-title} and Windows Machine Config Operator (WMCO) support updating from one EUS version to another EUS version of {product-title}, in a process called a *Control Plane Only* update. After upgrading the cluster, the Windows nodes are updated from the starting EUS version to the new EUS version while keeping the Windows workloads in a healthy state with no disruptions.
+[role="_abstract"]
+You can use the *Control Plane Only* process to update the {product-title} from one EUS version to another EUS version of {product-title}. After upgrading the cluster, the Windows nodes are updated the new EUS version. 


Not sure who does the upgrading? Also, should it be "updating"?

Suggested change

You can use the *Control Plane Only* process to update the {product-title} from one EUS version to another EUS version of {product-title}. After upgrading the cluster, the Windows nodes are updated the new EUS version.

You can use the *Control Plane Only* process to update the {product-title} from one EUS version to another EUS version of {product-title}. After you update the cluster, the Windows nodes are updated the new EUS version.

lahinson · 2026-06-12T18:55:07Z

+You can use the CSI PROXY plug-in to perform storage operations on the nodes in your cluster. 

-To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of link:https://kubernetes-csi.github.io/docs/drivers.html#production-drivers[production drivers] in the Kubernetes CSI Developer Documentation.
+{productwinc} installs CSI Proxy, which is a plug-in that enables CSI drivers for performing storage operations, on all Windows nodes in the cluster. For more information, use the CSI Proxy link the link in the "Additional resources" section.


Suggested change

{productwinc} installs CSI Proxy, which is a plug-in that enables CSI drivers for performing storage operations, on all Windows nodes in the cluster. For more information, use the CSI Proxy link the link in the "Additional resources" section.

{productwinc} installs CSI Proxy, which is a plug-in that enables CSI drivers for performing storage operations, on all Windows nodes in the cluster. For more information, see the CSI Proxy link in the "Additional resources" section.

lahinson · 2026-06-12T18:55:55Z

-To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of link:https://kubernetes-csi.github.io/docs/drivers.html#production-drivers[production drivers] in the Kubernetes CSI Developer Documentation.
+{productwinc} installs CSI Proxy, which is a plug-in that enables CSI drivers for performing storage operations, on all Windows nodes in the cluster. For more information, use the CSI Proxy link the link in the "Additional resources" section.
+
+To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of production drivers in the Kubernetes CSI Developer Documentation by using the link in the "Additional resources" section.


Suggested change

To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of production drivers in the Kubernetes CSI Developer Documentation by using the link in the "Additional resources" section.

To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of production drivers in the Kubernetes CSI Developer Documentation, which is linked in the "Additional resources" section.

lahinson · 2026-06-12T18:59:49Z

 The container base image must be the same Windows OS version and build number that is running on the node where the conainer is to be scheduled. 

-Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see link:https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11-21H2[Windows container version compatibility, Microsoft Windows documentation].
+Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see Windows container version compatibility in the Microsoft Windows documentation.


Suggested change

Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see Windows container version compatibility in the Microsoft Windows documentation.

Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see Windows container version compatibility in the Microsoft Windows documentation, which is linked in the "Additional resources" section.

openshift-ci · 2026-06-12T19:47:18Z

@mburke5678: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

mburke5678 · 2026-06-12T20:21:23Z

/cherrypick enterprise-4.20

mburke5678 · 2026-06-12T20:21:28Z

/cherrypick enterprise-4.21

mburke5678 · 2026-06-12T20:21:31Z

/cherrypick enterprise-4.22

mburke5678 · 2026-06-12T20:21:43Z

/cherrypick enterprise-5.0

openshift-cherrypick-robot · 2026-06-12T20:22:27Z

@mburke5678: new pull request created: #113294

Details

In response to this:

/cherrypick enterprise-4.22

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

openshift-cherrypick-robot · 2026-06-12T20:22:37Z

@mburke5678: new pull request created: #113295

Details

In response to this:

/cherrypick enterprise-5.0

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

mburke5678 added this to the Continuous Release milestone Jun 12, 2026

mburke5678 added branch/enterprise-4.20 branch/enterprise-4.21 branch/enterprise-4.22 labels Jun 12, 2026

mburke5678 added the branch/enterprise-5.0 label Jun 12, 2026

openshift-ci Bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jun 12, 2026

mburke5678 force-pushed the cqa-winc-1 branch from 3ce177b to 36ad913 Compare June 12, 2026 13:13

mburke5678 added the merge-review-needed Signifies that the merge review team needs to review this PR label Jun 12, 2026

mburke5678 changed the title ~~WINC-1: Windows Workload Management and Basics I~~ OSDOCS WINC-1: Windows Workload Management and Basics I Jun 12, 2026

mburke5678 changed the title ~~OSDOCS WINC-1: Windows Workload Management and Basics I~~ OSDOCS CQA WINC-1: Windows Workload Management and Basics I Jun 12, 2026

lahinson added merge-review-in-progress Signifies that the merge review team is reviewing this PR and removed merge-review-needed Signifies that the merge review team needs to review this PR labels Jun 12, 2026

lahinson reviewed Jun 12, 2026

View reviewed changes

lahinson added ok-to-merge and removed merge-review-in-progress Signifies that the merge review team is reviewing this PR labels Jun 12, 2026

WINC-1: Windows Workload Management and Basics I

c3ef458

mburke5678 force-pushed the cqa-winc-1 branch from 36ad913 to c3ef458 Compare June 12, 2026 19:36

mburke5678 merged commit 4127d91 into openshift:main Jun 12, 2026
2 checks passed

mburke5678 deleted the cqa-winc-1 branch June 12, 2026 20:20

openshift-cherrypick-robot mentioned this pull request Jun 12, 2026

[enterprise-4.22] OSDOCS CQA WINC-1: Windows Workload Management and Basics I #113294

Merged

openshift-cherrypick-robot mentioned this pull request Jun 12, 2026

[enterprise-5.0] OSDOCS CQA WINC-1: Windows Workload Management and Basics I #113295

Merged

openshift deleted a comment from openshift-cherrypick-robot Jun 12, 2026

This was referenced Jun 12, 2026

[enterprise-4.20] OSDOCS CQA WINC-1: Windows Workload Management and Basics I #113298

Merged

[enterprise-4.21] OSDOCS CQA WINC-1: Windows Workload Management and Basics I #113300

Merged

openshift deleted a comment from openshift-cherrypick-robot Jun 12, 2026

	If you want to disable the capability to run Windows container workloads, after uninstalling the Windows Machine Config Operator (WMCO), you can delete the namespace that was generated by default for the WMCO.
	If you want to disable the capability to run Windows container workloads, after you uninstall the Windows Machine Config Operator (WMCO), you can delete the namespace that was generated by default for the WMCO.

	For more information, see "Host and container version compatibility" in the Microsoft Windows documentation.
	For more information, see "Host and container version compatibility" in the Microsoft Windows documentation, which is linked in the "Additional resources" section.

	You can use the Control Plane Only process to update the {product-title} from one EUS version to another EUS version of {product-title}. After upgrading the cluster, the Windows nodes are updated the new EUS version.
	You can use the Control Plane Only process to update the {product-title} from one EUS version to another EUS version of {product-title}. After you update the cluster, the Windows nodes are updated the new EUS version.

	{productwinc} installs CSI Proxy, which is a plug-in that enables CSI drivers for performing storage operations, on all Windows nodes in the cluster. For more information, use the CSI Proxy link the link in the "Additional resources" section.
	{productwinc} installs CSI Proxy, which is a plug-in that enables CSI drivers for performing storage operations, on all Windows nodes in the cluster. For more information, see the CSI Proxy link in the "Additional resources" section.

	To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of production drivers in the Kubernetes CSI Developer Documentation by using the link in the "Additional resources" section.
	To use persistent storage with Windows workloads, you must deploy a specific Windows CSI driver daemon set, as described in your storage provider's documentation. By default, the WMCO does not automatically create the Windows CSI driver daemon set. See the list of production drivers in the Kubernetes CSI Developer Documentation, which is linked in the "Additional resources" section.

	Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see Windows container version compatibility in the Microsoft Windows documentation.
	Also, if you upgrade the Windows nodes from one version to another, for example going from 2022 to 2025, you must upgrade your container base image to match the new version. For more information, see Windows container version compatibility in the Microsoft Windows documentation, which is linked in the "Additional resources" section.

Conversation

mburke5678 commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jun 12, 2026

Uh oh!

ocpdocs-previewbot commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jun 12, 2026

Uh oh!

lahinson left a comment

Choose a reason for hiding this comment

Uh oh!

lahinson Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

lahinson Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

lahinson Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

lahinson Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

lahinson Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

lahinson Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

openshift-ci Bot commented Jun 12, 2026

Uh oh!

Uh oh!

mburke5678 commented Jun 12, 2026

Uh oh!

mburke5678 commented Jun 12, 2026

Uh oh!

mburke5678 commented Jun 12, 2026

Uh oh!

mburke5678 commented Jun 12, 2026

Uh oh!

openshift-cherrypick-robot commented Jun 12, 2026

Uh oh!

openshift-cherrypick-robot commented Jun 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

mburke5678 commented Jun 12, 2026 •

edited

Loading

ocpdocs-previewbot commented Jun 12, 2026 •

edited

Loading