fix(tests): stabilize AuthzITs and some other cleanups#3103
fix(tests): stabilize AuthzITs and some other cleanups#3103tombentley merged 6 commits intokroxylicious:mainfrom
Conversation
| apiKeys, | ||
| prettyJsonString(responseConverter.writer().apply(response, apiVersion)), | ||
| cluster.name()); | ||
| LOG.atDebug().setMessage("{} {} response: {} << {}") |
There was a problem hiding this comment.
Why change to debug here instead of using .atInfo() to match the previous behavior?
There was a problem hiding this comment.
In my opinion, these tests were writing too much output. I just want to see the names of test classes which is quick to eyeball when the tests run cleanly. When the test fails, I want the test to produce a good assertion message. I can then turn up logging if I need to to investigate the failure.
If tests spew war-and-peace on the happy path, that's disruptive for me.
kill some unused code. Signed-off-by: Keith Wall <kwall@apache.org>
…ually consistent nature of kafka Signed-off-by: Keith Wall <kwall@apache.org>
…sponse to ease reasoning about the differences Signed-off-by: Keith Wall <kwall@apache.org>
No problem. I'd been talking about the issue for a couple of days on Slack, so I'd assumed that everyone might have noticed. But we have too many channels for everyone to monitor everything! |
… to the broker before commencing the test Signed-off-by: Keith Wall <kwall@apache.org>
Signed-off-by: Keith Wall <kwall@apache.org>
| return scenario.clobberResponse(cl, node); | ||
| }); | ||
| assertThat(mapValues(proxiedResponsesByUser, | ||
| assertThatJson(mapValues(proxiedResponsesByUser, |
There was a problem hiding this comment.
This gives a much more human readable diff when the assertion fails.
| if (!scenario.needsRetry(r)) { | ||
| break; | ||
| } | ||
| try { |
There was a problem hiding this comment.
The sleep didn't seem to be achieving anything.
| <!-- </module>--> | ||
| <module name="IllegalImport"> | ||
| <!-- we shouldn't be relying on class shaded into TC for dependencies --> | ||
| <property name="illegalPkgs" value="org.testcontainers.shaded"/> |
...-integration-tests/src/test/java/io/kroxylicious/proxy/filter/authorization/KafkaDriver.java
Outdated
Show resolved
Hide resolved
…roxy/filter/authorization/KafkaDriver.java Signed-off-by: Tom Bentley <tombentley@users.noreply.github.com>
|
why: in kroxylicious#3103 666c64d we changed the AuthzIT tests to ensure that the topics were in a consistent state before the starting the tests. The AbstractAuthzEquivalenceIT tests have their own cluster prep code, so didn't benefit from this change meaning those tests could still fail owning to lack of consistency. This change pulls out a common base class and refactors both AuthzIT and AbstractAuthzEquivalenceIT to use it. Signed-off-by: Keith Wall <kwall@apache.org>
why: in kroxylicious#3103 666c64d we changed the AuthzIT tests to ensure that the topics were in a consistent state before the starting the tests. The AbstractAuthzEquivalenceIT tests have their own cluster prep code, so didn't benefit from this change meaning those tests could still fail owning to lack of consistency. This change pulls out a common base class and refactors both AuthzIT and AbstractAuthzEquivalenceIT to use it. Signed-off-by: Keith Wall <kwall@apache.org>
why: in kroxylicious#3103 666c64d we changed the AuthzIT tests to ensure that the topics were in a consistent state before the starting the tests. The AbstractAuthzEquivalenceIT tests have their own cluster prep code, so didn't benefit from this change meaning those tests could still fail owning to lack of consistency. This change pulls out a common base class and refactors both AuthzIT and AbstractAuthzEquivalenceIT to use it. Signed-off-by: Keith Wall <kwall@apache.org>
why: in kroxylicious#3103 666c64d we changed the AuthzIT tests to ensure that the topics were in a consistent state before the starting the tests. The AbstractAuthzEquivalenceIT tests have their own cluster prep code, so didn't benefit from this change meaning those tests could still fail owning to lack of consistency. This change pulls out a common base class and refactors both AuthzIT and AbstractAuthzEquivalenceIT to use it. Signed-off-by: Keith Wall <kwall@apache.org>
why: in kroxylicious#3103 666c64d we changed the AuthzIT tests to ensure that the topics were in a consistent state before the starting the tests. The AbstractAuthzEquivalenceIT tests have their own cluster prep code, so didn't benefit from this change meaning those tests could still fail owning to lack of consistency. This change pulls out a common base class and refactors both AuthzIT and AbstractAuthzEquivalenceIT to use it. Signed-off-by: Keith Wall <kwall@apache.org>
why: in kroxylicious#3103 666c64d we changed the AuthzIT tests to ensure that the topics were in a consistent state before the starting the tests. The AbstractAuthzEquivalenceIT tests have their own cluster prep code, so didn't benefit from this change meaning those tests could still fail owning to lack of consistency. This change pulls out a common base class and refactors both AuthzIT and AbstractAuthzEquivalenceIT to use it. Signed-off-by: Keith Wall <kwall@apache.org>
why: in #3103 666c64d we changed the AuthzIT tests to ensure that the topics were in a consistent state before the starting the tests. The AbstractAuthzEquivalenceIT tests have their own cluster prep code, so didn't benefit from this change meaning those tests could still fail owning to lack of consistency. This change pulls out a common base class and refactors both AuthzIT and AbstractAuthzEquivalenceIT to use it. Signed-off-by: Keith Wall <kwall@apache.org>



Type of change
Select the type of your PR
Description
The AuthzITs are unstable for me on my main work machine. We are also seeing the same failures in CI.
I am running this command:
The issues I'm seeing:
Side-effect assertion sporadically failing
The side effect assertions are failing. For instance, in
DeleteTopicsAuthzITI see failures like so:I think this is down the the eventually consistent nature of Kafka. Just because you've say, just created a topic, doesn't give you the guarantee that an admin observation will observe it.
Proxied/reference response mismatches
I'm seeing some fails like this:
This again is an eventually consistency issue. The test harness creates the topic (alice-topic etc), and then the test proceeds to perform an operation on the topic
Additional Context
Why are you making this pull request?
Checklist
Please go through this checklist and make sure all applicable tasks have been done