Bug 2102828
| Summary: | Cu requires guidance on windows container Vs OCP windows node version compatibility and best dev practices to avoid compatibility issues. | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Anand Paladugu <apaladug> |
| Component: | Documentation | Assignee: | Michael Burke <mburke> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jose Luis Franco <jfrancoa> |
| Severity: | high | Docs Contact: | Latha S <lmurthy> |
| Priority: | low | ||
| Version: | 4.10 | CC: | evmitche, mburke, rrasouli, rteague, ssoto |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-09-26 19:49:50 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Anand Paladugu
2022-06-30 18:38:23 UTC
This is covered in the OCP docs https://docs.openshift.com/container-platform/4.10/windows_containers/scheduling-windows-workloads.html#windows-pod-placement_scheduling-windows-workloads Based on the node version it looks like Windows Server, version 20H2 is being used? In that case the base image used to build the containers must be based off Windows 20H2. @ssoto That information is not quite obvious from out doc, but I have already shared the Microsoft link "Host and container version compatibility". I will open a doc bug to provide more clarity in this aspect. So is the simple answer that the base image version must always match the node version ? Are there issues if Customer upgrades nodes (which I dont know is a supported featured currently) with this approach. Also should the machine that you are building images on needs to have a matching os version ? and in general do we suggest any best practices to avoid compatibility issues ? > So is the simple answer that the base image version must always match the node version Yes that is correct. > Are there issues if Customer upgrades nodes If they upgrade their Windows instances from one 'variant' to another, say going from 20H2 to 2022, they will need to change their container images to match the new version. > Also should the machine that you are building images on needs to have a matching os version I'm unable to give advice around building Windows container images. > In general do we suggest any best practices to avoid compatibility issues Yes, they should make use of runtime classes https://docs.openshift.com/container-platform/4.10/windows_containers/scheduling-windows-workloads.html#creating-runtimeclass_scheduling-windows-workloads to remove the chance of a workload being scheduled on a Windows instance with an incompatible version. This is extremely important if the cluster has a mix of Windows Server variants, i.e some 20H2 some 2022 @ssoto Thank you. I am reaching out AnandNatraj (PM) for other questions. I see a reference to Microsoft matrix in our docs, but Cu clearly missed to take that pointer. Can I request that this be treated as a doc BZ and update our doc (below) to clarify that the container base image must match the windows version running on the OCP node and that the build number must match and as an additional data refer to Microsoft docs. https://docs.openshift.com/container-platform/4.10/windows_containers/scheduling-windows-workloads.html#windows-pod-placement_scheduling-windows-workloads Anand -- Please take a look at my PR to see if this meets your expectations. Thank you in advance. Michael https://github.com/openshift/openshift-docs/pull/49446 Anand, Russell, Sebastian In this paragraph from the docs, do "variant" and "version" mean the same thing? 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. 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. https://docs.openshift.com/container-platform/4.10/windows_containers/scheduling-windows-workloads.html#windows-pod-placement_scheduling-windows-workloads I would say essentially 'yes', variant and version are the same in this context. I think 'variant' may have come into play when talking about 'major versions' instead of 'minor versions'. The important part comes into play where you need to ensure the pod base image version is aligned with the host version. Microsoft documents the compatibility here [1] and they use the term 'version'. [1] https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility @rteague I am fine with the changes. However variant is not something I have heard in the Windows world. I did hear about it being used in the Linux world. So please see if it's appropriate to use Variant or Version. Thx Anand Also it seems many online references refer to windows build version as build number Refer to this about what the windows version and build numbers are: https://www.anoopcnair.com/windows-10-build-numbers-version-numbers/ I'm fine with using 'version' instead of 'variant'. Jose Luis and Ronnie -- Can one of you PTAL at my PR? Thank you in advance. Michael https://github.com/openshift/openshift-docs/pull/49446 Changes are live: https://docs.openshift.com/container-platform/4.11/windows_containers/scheduling-windows-workloads.html#windows-pod-placement_scheduling-windows-workloads Looking good, thanks for the change Mike. |