canonical / canonical/charm-integration-testing
Override needed for `oauth2-proxy-k8s`
- Dominant language
- Python
- Stars
- 6
- Forks
- 1
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 98
Description
**Note: This issue was generated with AI assistance (GitHub Copilot) based on automated log analysis and triage.**
Filed by @canonical/solutions-qa
`oauth2-proxy-k8s` (rev 24, deployed as `neighbor`) enters a crash loop and never reaches active status. Every startup attempt fails with:
```
ERROR: Failed to initialise OAuth2 Proxy: error initialising provider: ...
Get "https://10.141.5.23/.well-known/openid-configuration":
tls: failed to verify certificate: x509: cannot validate certificate for 10.141.5.23
because it doesn't contain any IP SANs
```
The OIDC issuer URL from Hydra is https://10.141.5.23/... (Traefik's external IP). The TLS certificate served by Traefik (issued by `self-signed-certificates`) has no IP SAN for that address, so Go's TLS stack rejects it unconditionally.
The charm itself warns:
```
Missing certificate_transfer integration, run juju config oauth2-proxy-k8s dev=true to skip validation of certificates presented when using HTTPS providers. Don't do this in production
```
The bundle (test plan integration/hydra:oauth/oauth/oauth2-proxy-k8s:oauth) is missing a fix for the self-signed TLS in the test environment. Two viable fixes:
1. Add dev: true config to the neighbor (oauth2-proxy-k8s) application in the bundle
2. Add certificate_transfer integration: self-signed-certificates:certificate-transfer → neighbor:receive-ca-cert (though this alone may not fix the IP SAN error)
**Human Note**: It's debatable whether there is also a bug in the `oauth2-proxy-k8s` charm. It enters a `MaintenanceStatus`, when perhaps a `BlockedStatus` would be more appropriate. That said, either one would block our tests, so I'm starting with an issue for the override.
Contributor guide
Research direction
Start by locating the bundle for test plan integration/hydra:oauth/oauth/oauth2-proxy-k8s:oauth and inspect the neighbor application configuration and existing integrations. Compare the dev: true override with certificate_transfer, then run the affected integration test to confirm oauth2-proxy-k8s reaches active status without the TLS crash loop.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- devops, infrastructure, testing-qa
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100