Provide docker containers based on Server Core LTSC 2019 and 2022
yodaldevoid opened this issue · 3 comments
Checklist
- I have verified this is the correct repository for opening this issue.
- I have verified no other issues exist related to my request.
Is Your Feature Request Related To A Problem? Please describe.
No response
Describe The Solution. Why is it needed?
Windows containers must match the version of Windows host they are run on when running in process isolation mode. This means that the current Chocolatey Docker container cannot run on all versions of Windows where HyperV isolation is not possible.
To solve this problem, more versions of the Windows container should be distributed. Providing LTSC 2019 and 2022 based containers would cover a significantly larger population of Windows installs.
Additional Context
No response
Related Issues
No response
@TheCakeIsNaOH as you were involved in the Docker images, can you comment on this? I have a feeling there was a similar issue or comment about this some time ago, but I couldn't find anything when I searched. I do have it in my head that the current image is usable on LTSC 2019 and 2022.
I do have it in my head that the current image is usable on LTSC 2019 and 2022.
The current image is usable on LTSC 2019 and 2022 if HyperV isolation is used, but not all setups allow for HyperV isolation.
I do have it in my head that the current image is usable on LTSC 2019 and 2022.
The current image is usable on LTSC 2019 and 2022 if HyperV isolation is used, but not all setups allow for HyperV isolation.
That compatibility matches my understanding. I was not aware that some setups did not allow for Hyper-V isolation, but since there are, then creating images based on these other base images would likely be useful.
As is, this is very easy to do from a public source perspective, just copy-paste the Dockerfile.windows and change the base tag to 2019 and 2022 (or change the tag to a variable and pass in the tag during build). However, the potentially more complex operation would be to build the 2022 image on the internal CI/CD, as then the 2022 image would have to be built on a Server 2022 host OS. Additionally, the CI build scripts (and maybe the Cake script?) would have to be updated to handle multiple Windows images.