Details
-
Story
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
False
-
False
-
Undefined
-
5
-
Sprint 223, Sprint 224, Sprint 225, Sprint 226, Sprint 227, Sprint 228, Sprint 229, Sprint 230, Sprint 231, Sprint 232, Sprint 233, Sprint 234, Sprint 235, Sprint 236, Sprint 237
-
0
-
0.0
Description
Per the 4.6.30 Monitoring DNS Post Mortem, we should add E2E tests to openshift/cluster-dns-operator to reduce the risk that changes to our CoreDNS configuration break DNS resolution for clients.
To begin with, we can scope this story to 2 or 3 client libraries to establish a framework for testing DNS resolvers; the work of adding additional client libraries to this framework can be left for follow-up stories. Two common libraries are Go's resolver and glibc's resolver. A somewhat common library that is known to have quirks is musl libc's resolver, which uses a shorter timeout value than glibc's resolver and reportedly has issues with the EDNS0 protocol extension. It would also make sense to test Java or other popular languages or runtimes that have their own resolvers.
The ultimate goal is that the test will inform us when a change to OpenShift's DNS or networking has an effect that may impact end-user applications.
Attachments
Issue Links
- links to