Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --aks-engine-azure-windows-master-staging ServiceAccounts ServiceAccountIssuerDiscovery should support OIDC discovery of service account issuer [Conformance] /sig windows /cc
cc
/assign
/assign Let me know if you want to pair on this
We took a look at this for docker case and we believe it is happening due to Windows DNS networking limitations. DNS can be available sometime after the container starts due to the way networking is set up with docker. In containerd the setup steps are different so the network will be available when the container starts. In this case the test image does a lookup before the DNS is finished coming online and fails.
it fails in linux as well
From the link posted, it looks like the test cluster issuer might be misconfigured (--service-account-issuer is missing https, I'm not sure why this even passed kube-apiserver validation, double-checking that also): Try setting on kube-apiserver.
reminded me we couldn't actually add that validation, because we weren't previously validating schemes and it would've broken existing clusters with bad issuers set... So as far as fixing the tests make sure issuers have schemes, at least.
I guess the config in this case is managed behind AKS service, and AKS has been setting without https scheme?
Thanks! The failures on the Linux tests are a separate issue from the Windows failures on docker. I opened kubernetes-sigs/cloud-provider-azure to resolve the Linux failures (we have already done this for Windows: )
/reopen This is still an issue for windows docker. fixes it
Reopened this issue. <detailsIn response to : /reopen This is still an issue for windows docker. fixes it 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
I'm glad this was fixed for open-source test configs, but I assume since the test said "aks" in the name this could be an issue for managed Azure clusters? Clients should reject issuers without https instead of attempting to validate them, so we'd want all clusters to be using https scheme in the issuer URL, but at the same time, changing the issuer URL on an existing cluster invalidates previously-issued tokens, because kube-apiserver would no longer recognize the old issuer. I just want to confirm that what was happening with tests isn't foreshadowing a bigger issue for existing Azure clusters. can you/someone at Microsoft confirm? FYI
We use aks-engine (self-managed cluster instead of managed AKS cluster) to run the tests. For aks-engine, I opened a PR () to fix the service account issuer. For AKS, I can confirm that the service account issuer does not any scheme in the URL at all. Tagging who works on aks-engine. Tagging who works on AKS.
We confirmed that is being fixed in AKS.
/traige accepted /milestone v1.21 /priority important-soon
/triage accepted
Our ipv6 test is still failing: The service issuer has been set to .
that seems to be a different issue than Windows. could you open a new issue and tag and me?

Discussion:
# then after merge and successful postsubmit image push / promotion, bump this - name: "agnhost: dependents" <del> version: "2.29" </del> <ins> version: "2.30" </ins> refPaths: - path: test/utils/image/manifest.go match: configs[Agnhost] = Config{promoterE2eRegistry, "agnhost", "d+.d+"}

func initImageConfigs() (map[int]Config, map[int]Config) { configs := map[int]Config{} <del> configs[Agnhost] = Config{promoterE2eRegistry, "agnhost", "2.29"} </del> <ins> configs[Agnhost] = Config{promoterE2eRegistry, "agnhost", "2.30"} </ins> configs[AgnhostPrivate] = Config{PrivateRegistry, "agnhost", "2.6"} configs[AuthenticatedAlpine] = Config{gcAuthenticatedRegistry, "alpine", "3.7"} configs[AuthenticatedWindowsNanoServer] = Config{gcAuthenticatedRegistry, "windows-nanoserver", "v1"}