Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Hyper-v support was as an for docker. Hyper-v support is now focused on Containerd because of better support of HCSv2 in Containerd (for example allows for multiple containers in a pod in hyper-v). There is still annotation support that should be removed in all the various locations: What you expected to happen: hyper-v support for docker will not go past alpha so the annotations should be depreciated following the guidelines at How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Windows Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig windows
/remove-kind bug /kind deprecation cleanup /sig node
I can try to contribute to solve this issue /assign
Do we need to discuss whether we confirm that we need to remove this feature in the kubernetes code? If it is removed, it will not support running hyper-v-based windows container through docker.
We can add it to the agenda for sig-windows next week to confirm. There is no path forward for hyper-v containers with docker so it should be ok to remove via standard depreciation mechanisms. We have been working to get hyper-v working via containerd (still work in progress) and have tests passes:
What is the process for announcing and removing an experimental annotation? I read through but it mostly refers to api changes.
I submitted a simple pr for this issue, we can follow up the results of the discussion next week for further operations
I also read this document and found that there is a short description related to this issue I am confused about this point. It seems that the feature of hyper-v can be removed (because it has been in alpha for a long time, experimental feature), I don’t know if my understanding is correct.
alpha feature gates can be removed without a deprecation period in release N+1 if in release N - i.e. it could have been removed in 1.11 as per the minimum policy. this is the recommended minimum and exceptions can feature existed for 10 releases and Windows containers support existed for a few releases as well, which means you could have production clusters using the feature. my recommendation would be to announce this as deprecated in 1.20 and remove in 1.21. PRs with release-notes prefixed with "action required: ..." would end up on top of the release change logs to alert users. ideally sig-windows should decide on the timing. cc
+1. Could we add a warning log and an announcement in v1.20 and then remove it in v1.21?
If sig-windows has the latest discussion results, please let me know and I can try to follow up this issue
We and agree should be a log warning for depreciation in 1.20 and remove support in v1.21. can you update the PR to log the warning and add the appropriate release note?
i open a new pr for log warning message for this issue
This should stay open as a tracking issue untill the feature is removed in 1.21
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale

Discussion:
// alpha: v1.10 // // Enable Hyper-V containers on Windows <ins> // Deprecated in 1.20 and removed in 1.21 </ins> HyperVContainer featuregate.Feature = "HyperVContainer" // owner: @mikedanese

StorageObjectInUseProtection:   {Default: true, PreRelease: featuregate.GA}, SupportPodPidsLimit:            {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.21 SupportNodePidsLimit:           {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.21 <del> HyperVContainer:                {Default: false, PreRelease: featuregate.Alpha}, </del> <ins> HyperVContainer:                {Default: false, PreRelease: featuregate.Deprecated}, </ins> TokenRequest:                   {Default: true, PreRelease: featuregate.Beta}, TokenRequestProjection:         {Default: true, PreRelease: featuregate.Beta}, BoundServiceAccountTokenVolume: {Default: false, PreRelease: featuregate.Alpha},

"@io_bazel_rules_go//go/platform:windows": [ "//pkg/features:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", <ins> "//vendor/k8s.io/klog/v2:go_default_library", </ins> ], "//conditions:default": [], }),

import ( utilfeature "k8s.io/apiserver/pkg/util/feature" <ins> "k8s.io/klog/v2" </ins> "k8s.io/kubernetes/pkg/features" )

// ShouldIsolatedByHyperV returns true if a windows container should be run with hyperv isolation. func ShouldIsolatedByHyperV(annotations map[string]string) bool { <ins> klog.Warningf("The hyper-v FeatureGate is deprecated in 1.20 and will be removed in 1.21") </ins> if !utilfeature.DefaultFeatureGate.Enabled(features.HyperVContainer) { return false }