-
Notifications
You must be signed in to change notification settings - Fork 212
Improve DNS validation in connectivity test #933
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
ceb3dfa
to
962a6cd
Compare
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.
Awesome work, thanks! A couple very minor nits
962a6cd
to
0fcc26b
Compare
0fcc26b
to
233dbec
Compare
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.
Nice work, thanks Fabio!
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.
Good stuffs 💯
Opened #940 for the multicluster workflow failure and re-triggered the job. |
The 2nd and 3rd runs of the multicluster workflow both failed with an issue other than #940 (that one happened on the 1st run):
https://github.com/cilium/cilium-cli/runs/7005064156?check_suite_focus=true Looks like this could be related to this PR itself. @pippolo84 could you take a look, please? |
Sure, I'll look into it. |
233dbec
to
2d70e9f
Compare
The job was failing due to a missing ConfigMap in the second cluster used in the multicluster setup. |
Validate DNS in connectivity test against a server located in the same node, then against a server located on another node and finally against the DNS service. This eliminates any kind of randomness in the test result, possibly due to the location of the DNS service pod. The DNS server used is CoreDNS, with the "local" plugin. To activate that plugin a Corefile is needed, so a ConfigMap is created in each cluster where the server will be deployed. Fixes #880 Signed-off-by: Fabio Falzoi <fabio.falzoi@isovalent.com>
2d70e9f
to
c0cf53f
Compare
This time it was an issue related to an incorrect use of the source cluster client instead of the destination cluster client, where the |
Awesome work @pippolo84! |
Looks like this test failed when I use the cilium-cli v0.11+ while all the tests in cilium-cli v0.9.1 passed
|
Thanks for the report. Could you provide more details (e.g. Hubble output of the failing test) and maybe even a sysdump of the system? |
The first step of the connectivity check is to test the DNS.
Since the DNS service pod may be located either on the same node of the client or on any other node, the test may introduce randomness, depending on how the connectivity is actually broken (e.g. same-node connectivity only is broken or across-nodes connectivity only is broken).
To guarantee a reliable check, the connectivity test has been extended to perform the following step for each client:
To perform the first two steps, the already existing
echo-same-node
andecho-other-node
deployments have been modified to deploy a multi-container pod containing a test CoreDNS server.The test CoreDNS server is configured with the
local
plugin, to be able to answer a mock DNS request forlocalhost
. This should be enough to validate that DNS is working correctly.Fixes #880
Signed-off-by: Fabio Falzoi fabio.falzoi@isovalent.com