capz-windows-master-hyperv-serial-slow: re-enable 3 GC/SchedulerPreemption specs

[rzlink]

What this PR does

Re-enables 3 previously-skipped Kubernetes e2e specs on the
capz-windows-master-hyperv-serial-slow testgrid dashboard:

• [sig-api-machinery] Garbage collector should not delete dependents that have both valid owner and owner that's waiting for dependents to be deleted [Serial] [Conformance]
• [sig-api-machinery] Garbage collector should orphan pods created by rc if delete options say so [Serial] [Conformance]
• [sig-scheduling] SchedulerPreemption [Serial] validates pod disruption condition is added to the preempted pod [Conformance]

These were originally skipped because they consistently OOM'd Windows worker nodes under Hyper-V isolation due to per-pod vmmem.exe overhead exceeding the kubelet's hard-eviction threshold on 16 GiB D4s_v3 workers.

Why this is safe now

The root cause was excessive Hyper-V pod density: with the default --max-pods=110, the e2e helper estimateMaximumPods(min=10, max=100) would request up to 100 pods per node, and each pod added ~500-700 MiB
of vmmem host overhead invisible to pod-level kubelet stats.

The MAX_PODS=20 cap added in kubernetes-sigs/windows-testing#567 and test-infra#37141
reduces this to at most 20 pods/node, keeping the 3 specs comfortably inside available memory.

/sig windows
/area provider/azure
/cc @marosset @zylxjtu

[k8s-ci-robot]

Hi @rzlink. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[marosset]

/ok-to-test
/approve
/hold for CI test

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: marosset, rzlink

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• config/jobs/kubernetes-sigs/sig-windows/OWNERS [marosset]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[marosset]

/hold cancel
we don't have a ci test for the hyperv + serial slow
/lgtm

[k8s-ci-robot]

@rzlink: Updated the job-config configmap in namespace default at cluster test-infra-trusted using the following files:

• key release-master-windows.yaml using file config/jobs/kubernetes-sigs/sig-windows/release-master-windows.yaml

Details

In response to this:

What this PR does

Re-enables 3 previously-skipped Kubernetes e2e specs on the
capz-windows-master-hyperv-serial-slow testgrid dashboard:

• [sig-api-machinery] Garbage collector should not delete dependents that have both valid owner and owner that's waiting for dependents to be deleted [Serial] [Conformance]
• [sig-api-machinery] Garbage collector should orphan pods created by rc if delete options say so [Serial] [Conformance]
• [sig-scheduling] SchedulerPreemption [Serial] validates pod disruption condition is added to the preempted pod [Conformance]

These were originally skipped because they consistently OOM'd Windows worker nodes under Hyper-V isolation due to per-pod vmmem.exe overhead exceeding the kubelet's hard-eviction threshold on 16 GiB D4s_v3 workers.

Why this is safe now

The root cause was excessive Hyper-V pod density: with the default --max-pods=110, the e2e helper estimateMaximumPods(min=10, max=100) would request up to 100 pods per node, and each pod added ~500-700 MiB
of vmmem host overhead invisible to pod-level kubelet stats.

The MAX_PODS=20 cap added in kubernetes-sigs/windows-testing#567 and test-infra#37141
reduces this to at most 20 pods/node, keeping the 3 specs comfortably inside available memory.

/sig windows
/area provider/azure
/cc @marosset @zylxjtu

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.