Bug 2102828 - Cu requires guidance on windows container Vs OCP windows node version compatibility and best dev practices to avoid compatibility issues.
Summary: Cu requires guidance on windows container Vs OCP windows node version compati...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 4.10
Hardware: Unspecified
OS: Unspecified
low
high
Target Milestone: ---
: ---
Assignee: Michael Burke
QA Contact: Jose Luis Franco
Latha S
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-06-30 18:38 UTC by Anand Paladugu
Modified: 2022-09-27 05:16 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-26 19:49:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Anand Paladugu 2022-06-30 18:38:23 UTC
Must gather logs:

1. Issue: Cu requires guidance on windows container Vs OCP windows node version compatibility and best dev practices to avoid compatibility issues.

2. WMCO & OpenShift Version 5.x and 4.10 

3. Platform - AWS/Azure/VSpehre/Platform=VSphere

4. If the platform is vSphere, what is the VMware tools version?


6. Steps to Reproduce

docker run of a container build using https://github.com/microsoft/dotnet-framework-docker/tree/main/samples/dotnetapp


7. Actual Result and Expected Result

Docker run fails with "docker: error response from daemon: hcsshim::CreateComputerSystem  e1................8454: The container operating systems does not match the host operating system.


Another image downloaded from microsoft "mcr.microsoft.com/dotnet/framework/samples:dotnetapp" runs fine.  The difference seems to be the container os version.  All versions are attached to the case 


Failed container os version:  10.0.14393.5192
successful container os version: 10.0.19042.1766
OCP windows node version:  10.0.19042.1706

Cu is asking for guidance on best practices for container development.  

1. What is the min container os version given a node version. 
2. Best practices to avoid compatibility issues.

Suggested Cu to also involve Microsoft and shared several articles with them like below, but they are looking for answers from us at a foundational level since we own the platform.

https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/update-containers
https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-base-images

Comment 1 Sebastian Soto 2022-06-30 19:02:36 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.

Comment 2 Anand Paladugu 2022-06-30 19:23:40 UTC
@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.

Comment 3 Anand Paladugu 2022-06-30 19:33:34 UTC
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 ?

Comment 5 Sebastian Soto 2022-07-05 14:29:11 UTC
> 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

Comment 6 Anand Paladugu 2022-07-06 12:17:27 UTC
@ssoto  Thank you.  I am reaching out AnandNatraj (PM) for other questions.

Comment 8 Anand Paladugu 2022-07-12 20:37:38 UTC
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

Comment 10 Michael Burke 2022-08-22 16:22:21 UTC
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

Comment 11 Michael Burke 2022-08-22 16:25:20 UTC
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

Comment 12 Russell Teague 2022-08-22 16:47:11 UTC
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

Comment 13 Anand Paladugu 2022-08-31 16:49:48 UTC
@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

Comment 14 Anand Paladugu 2022-08-31 17:00:24 UTC
Also it seems many online references refer to windows build version as build number

Comment 15 Anand Paladugu 2022-08-31 17:01:16 UTC
Refer to this about what the windows version and build numbers are:

https://www.anoopcnair.com/windows-10-build-numbers-version-numbers/

Comment 16 Russell Teague 2022-09-12 17:12:56 UTC
I'm fine with using 'version' instead of 'variant'.

Comment 17 Michael Burke 2022-09-23 20:50:42 UTC
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

Comment 18 Michael Burke 2022-09-26 18:06:13 UTC
Merged PR https://github.com/openshift/openshift-docs/pull/50876

Comment 20 Jose Luis Franco 2022-09-27 05:16:26 UTC
Looking good, thanks for the change Mike.


Note You need to log in before you can comment on or make changes to this bug.