KAFKA-2846: Add Ducktape test for kafka-consumer-groups#555
KAFKA-2846: Add Ducktape test for kafka-consumer-groups#555SinghAsDev wants to merge 3 commits intoapache:trunkfrom
Conversation
|
@granders @guozhangwang mind taking a look? |
|
@granders @guozhangwang pinging again for review. I just rebased it over latest trunk. Thanks! |
|
@ewencp do you mind taking a look at this, it has been pending for quite some time now. Thanks! |
There was a problem hiding this comment.
How necessary is it to test this with SSL? @hachikuji any thoughts on this?
There was a problem hiding this comment.
Why all the different security variants? Are we actually concerned that these wouldn't work -- are the different variants actually providing value? If they are, is there any reason to have the variants on all of these tests rather than just on 1 of them (i.e. why would we think that if it works using a secured cluster on test_list_consumer_groups, why wouldn't it on test_describe_consumer_groups)?
There was a problem hiding this comment.
@granders I agree with @ewnecp that covering all the protocols doesn't seem to add much value.
There was a problem hiding this comment.
Good question. Below are the combinations for ConsumerGroupCommand.
OldConsumer
NewConsumer
NewConsumer + Security
I chose to test following combinations and I think it is reasonable.
OldConsumer
NewConsumer + Security
I also think these tests are to make sure we catch regressions in future. If something is working today, it does not mean it will always work. Also, note that I am not testing against all protocols.
why would we think that if it works using a secured cluster on test_list_consumer_groups, why wouldn't it on test_describe_consumer_groups
Sure, it works today. These tests are supposed to check regressions. {{LIST_GROUPS}} and {{DESCRIBE_GROUPS}} have different code paths, request/responses, etc. I see that as a strong reason to test both of them.
SinghAsDev
force-pushed
the
KAFKA-2846
branch
from
55d8c94 to
2e35e67
Compare
…on for classic-to-diskless migration (apache#555) When diskless.allow.from.classic.enable is true and a topic is being migrated from classic (remote.storage.enable=true) to diskless, skip the mutual exclusion validation that prevents both configs from being set simultaneously. The bypass only triggers when all conditions are met: - diskless.allow.from.classic.enable is true (broker config) - diskless.enable is being explicitly set to true (request) - remote.storage.enable was previously set to true (existing topic config)
4 participants
No description provided.