/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: https://testgrid.k8s.io/sig-windows-containerd#aks-engine-azure-windows-master-containerd-hyperv

@neolit123 What is the process for announcing and removing an experimental annotation? I read through https://kubernetes.io/docs/reference/using-api/deprecation-policy/ 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

@neolit123 What is the process for announcing and removing an experimental annotation? I read through https://kubernetes.io/docs/reference/using-api/deprecation-policy/ but it mostly refers to api changes.

I also read this document and found that there is a short description related to this issue

https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior

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 added 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 happen...the 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 @feiskyer @benmoss @ddebroy

my recommendation would be to announce this as deprecated in 1.20 and remove in 1.21.

+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 discussed this at sig-windows and agree should be a log warning for depreciation in 1.20 and remove support in v1.21.

@wawa0210 can you update the PR to log the warning and add the appropriate release note?

@wawa0210 can you update the PR to log the warning and add the appropriate release note?

#95505

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

@jsturtevant: Reopened this issue.

@jsturtevant: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale