Refactor gateway listener in dns section target test#799
Refactor gateway listener in dns section target test#799azgabur merged 1 commit intoKuadrant:mainfrom
Conversation
17cdb58 to
d223cc1
Compare
averevki
left a comment
There was a problem hiding this comment.
Good catch, but why do you want to use tlspolicy together with dnspolicy in this test? It should only test the section name change in dnspolicy. More atomic, if you will 😁
|
Yes another solution is to make the clients http, which is maybe better solution come to think of it 🤔 The test can have wildcard listener as the more specific hostname listener will be used instead of the wildcard when a request comes, of course not if they are on different ports as happened here.. You could remove the default listener and have only the managed and unmanaged ones but it makes little difference. I will add it regardless |
Signed-off-by: Alex Zgabur <azgabur@redhat.com>
d223cc1 to
352adca
Compare
|
/make dnstls |
|
Test run completed ( Short Test SummaryFull Output |
|
Test run completed ( Short Test SummaryFull Output |
|
@azgabur I'm looking at the last CI run and I don't quite understand the failure - dns.resolver.NoAnswer. Could you explain what this failure means, please? |
|
The github action bot and also my local ISP provider have access to dns resolvers that check dnssec so the error on some tests happening when
I will take a look at second solution if it wont be feasible I will just turn off the dnssec |
|
thanks for explanation! |
The test worked previously too, but the gateway setup had one flaw. Resulting gateway had the default wildcard listener and the additional managed and unmanaged listeners, but these were http only. The client fixtures were using https protocol so it actually connected to the wildcard listener instead, not the managed or unamanaged listener.
I know this is a small change and it has no impact on the test result but for the future if the test would be changing it would solve some debugging time..
to verify: