This adds more tests around the kafka client quota api with kafka-configs.sh which is the main non-rpk client that we expect this api to be used with. This testing also discovered a bug in the alter implementation where the entries[].entity field in the response was not filled -- kafka-configs.sh expects this to be set.
Note that kafka-configs.sh won't see any responses with the client-id-prefix entity type, so we won't and can't test that. This is because kafka-configs.sh only sends requests with the strict field set to true (See here only ClientQuotaFilter.containsOnly(...) is ever used).
As an alternative way of testing against kafka-configs.sh I considered abstracting over the alter and describe methods of rpk and kafka-configs.sh and running the existing tests against kafka-configs.sh as well, but that quickly became overly complicated because of the differences between rpk and kafka-configs.sh (kafka-configs.sh only does strict matching, kafka-configs.sh doesn't support client-id-prefix entity types), so I opted for a simpler but still high coverage test for kafka-configs.sh.
For now, I think rpk and kafka-configs.sh are the only clients that are worth testing against. I could not find any others.
This adds more tests around the kafka client quota api with kafka-configs.sh which is the main non-rpk client that we expect this api to be used with. This testing also discovered a bug in the alter implementation where the
entries[].entityfield in the response was not filled -- kafka-configs.sh expects this to be set.Note that kafka-configs.sh won't see any responses with the client-id-prefix entity type, so we won't and can't test that. This is because kafka-configs.sh only sends requests with the
strictfield set totrue(See here onlyClientQuotaFilter.containsOnly(...)is ever used).As an alternative way of testing against kafka-configs.sh I considered abstracting over the alter and describe methods of rpk and kafka-configs.sh and running the existing tests against kafka-configs.sh as well, but that quickly became overly complicated because of the differences between rpk and kafka-configs.sh (kafka-configs.sh only does strict matching, kafka-configs.sh doesn't support client-id-prefix entity types), so I opted for a simpler but still high coverage test for kafka-configs.sh.
For now, I think rpk and kafka-configs.sh are the only clients that are worth testing against. I could not find any others.
Fixes https://redpandadata.atlassian.net/browse/CORE-2700
Backports Required
Release Notes
none