-
Notifications
You must be signed in to change notification settings - Fork 3.4k
test/runtime: remove already covered FQDN tests #38866
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
/test |
aa5b08f
to
4c446e4
Compare
/test |
4c446e4
to
f69a125
Compare
/test |
f69a125
to
aa666e3
Compare
/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I fully get what we're trying to assert re DNSSEC and whether www.cilium.io actually has DNSSEC enabled
cilium-cli/connectivity/builder/manifests/client-egress-only-dns-world.yaml
Outdated
Show resolved
Hide resolved
The existing FQDN runtime test only checks for the existence of an Changing the PR to just remove the respective test without replacement. |
Pull request was converted to draft
matchPattern *
tests
d2a1f76
to
32414ca
Compare
/ci-runtime |
/test |
1 similar comment
/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Cilium DNS proxy doesn't seem to touch RRSIG records at all.
Could it be that the intent of the test is verifying that the DNS proxy doesn't drop DNSSEC records? I think the upstream DNS servers of www.cilium.io serve RRSIGs (i.e. root and authoritative NS) so if we drop those that could be a problem. But I think this is easily testable at the unit/component level (and may already be covered).
Yeah, might be that that was the original intent, though neither the commit message nor the PR description mention anything specific. But as you say, this is in any case better off in a unit test. I'm planning to add one for |
The existing FQDN runtime test only checks for the existence of an RRSIG record in the DNS response[^1]. The Cilium DNS proxy doesn't touch RRSIG records at all. So it looks like the existing test is already of limited use and can be removed without replacement. [^1]: https://github.com/cilium/dnssec-client/blob/master/client.py#L30-L32 Signed-off-by: Tobias Klauser <tobias@cilium.io>
…* test matchPattern * is already covered in existing Cilium CLI connectivity tests, though not for subdomains currently. However, the correct application of the provided pattern to FQDNs is already covered in various unit tests in pkg/fqdn. Thus the corresponding runtime FQDN test case is redundant and can be removed. Signed-off-by: Tobias Klauser <tobias@cilium.io>
matchPattern *
tests32414ca
to
9035722
Compare
/test |
The policy used in the test doesn't have a toPorts.rules.dns rule, so the DNS proxy isn't covered at all in the test. This test is thus testing the default-deny behavior which is already covered elsewhere, e.g. various Cilium CLI connectivity tests. Signed-off-by: Tobias Klauser <tobias@cilium.io>
9035722
to
c415376
Compare
FYI, I've pushed an additional commit removing one more test that wasn't even exercising the DNS proxy and was thus only testing default-deny behavior. |
/test |
Remove three more tests from the runtime FQDN test suite that are either already covered by existing tests or are of limited use.
For #37838