Change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: ci-kubernetes-e2e-aks-engine-azure-master-staging-windows Which test(s) are flaking: There is a race condition in the one of the tests and they are run in parallel so if varies, some of the recent ones are: Testgrid link: https://k8s- Reason for failure: gmsa webhooks is not responding: The gmsa test creates the webhook and then removes it when the test is complete: causing failures for any running tests Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated /sig windows /assign
thanks for helping track this down
The current plan is to move the deployment of the webhook out of the individual test and make sure it is installed at cluster provisioning time. do you see any issues? It doesn't look like the gce tests run the tests so this should not affect the tests runs there but in the future if would need to be set up in test scripts. fyi -
hey yes, deploying the webhook at cluster deployment definitely works. It was scoped to the test to reduce blast radius when things weren't super stable.
One alternative to creating the webhook at provisioning time ( I still thing this is the cleaner version of the fix ), we can just mark GMSA tests [SERIAL], thus we won't have a problem with this race.
I looked into this some more and found we have three options: Install the webhook at provisioning time. This solved the problem above but causes the test to fail because the webhook looks for a gmsa CRD and . One option is to update the test to add a crd in the case the webhook is installed Update the gMSA webhook to allow requests that do not have the name set but do have the set. This would allow the "GMSA Kubelet" test to pass because it would not be rejected by the webhook. Mark the tests as which would move the test out of the parallel jobs and allow the test to still function. I am leaning towards the third option as the first option of modifying the "kubelet GMSA" test would be adding extra steps (installing crd and RBAC roles) that have nothing to do with the test. The second option seems like it could be a fair change to the webhook but I don't know enough about the rest of the webhook logic and design and would be a change in behavior of the webhook. The third option is simpler but would require changes to the serial tests to enable the domain controller. The benefit would be that the tests that run in parallel wouldn't require domains controller to be set up which would speed up provision time and after I ran an experimental test run indicated that it might bring the test runs under 1hr (currently 1.4hrs). It would add some additional time to the serial tests which are already pretty slow (3+ hrs). do you have any thoughts?

Discussion:
gmsaWebhookDeployScriptURL = "https://raw.githubusercontent.com/kubernetes-sigs/windows-gmsa/master/admission-webhook/deploy/deploy-gmsa-webhook.sh" ) <del> var _ = SIGDescribe("[Feature:Windows] GMSA Full [Slow]", func() { </del> <ins> var _ = SIGDescribe("[Feature:Windows] GMSA Full [Serial] [Slow]", func() { </ins> f := framework.NewDefaultFramework("gmsa-full-test-windows") ginkgo.Describe("GMSA support", func() {