-
Notifications
You must be signed in to change notification settings - Fork 593
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
CI Failure (kafka-topics.sh --alter --topic --partitions 7
fails with "Partition count must be greater then current number of partitions") in ControllerUpgradeTest.test_updating_cluster_when_executing_operations
#8637
Comments
There is something strange going on here between the AdminServer, rpk, and registering new partitions.
It is important to note that one of the brokers was down for the entire duration when we were increasing partition count from 6->11.
Therefore, I'm adding |
My guess it's caused the same problem as #8562 which was supposed to be fixed in #8569 The guess is that Probably the test should not depend on rpk and use admin api to query and wait until all nodes are updated. // cc @mmaslankaprv |
exactly as @rystsov said it is a bug in test related with eventual consistency of metadata. |
@mmaslankaprv is this a ticket your team is taking up? i can't quite figure out if this is an area/kafka issue |
@dotnwat it's common thing but initially was introduced by the replication team, putting it in our queue |
Is this a sev/low though given it appears to be a test bug than a Redpanda one? |
marked as sev/low as this is test setup issue |
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
https://buildkite.com/redpanda/redpanda/builds/23564#01866ea0-18d6-4480-b837-c726ba0b6b48 This is a different backtrace but also appears to be a CLI tool complaining about something out of whack with metadata
|
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
I ran into another failure mode here (similar to the one John encountered), but reading through the ticket, I think the cause may be the same. In this case, the partition was not found within the 5 retries:
|
looks like a similar issue: https://buildkite.com/redpanda/redpanda/builds/24566#0186bd22-ca67-4000-8962-e7a32a39050f
|
looks like a similar issue as well: on (amd64, container) in job https://buildkite.com/redpanda/redpanda/builds/24566#0186bd22-ca67-4000-8962-e7a32a39050f
although this time
and immediatelly after that
|
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com>
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
Since metadata are eventually consistent we query all nodes about current partition count of a topic. Only if all values are the same we allow to execute add partitions operation. This way operation result will always be deterministic. Fixes: redpanda-data#8637 Signed-off-by: Michal Maslanka <michal@redpanda.com> (cherry picked from commit aab3b0c)
https://buildkite.com/redpanda/redpanda/builds/22535
The chronology of the error:
fuzzy-operator-1365-odqcci
was created with 1 partition, then upgraded to 4, then to 6, and from 6 is was upgraded to 11 before the issues started.rpk topic describe
still reports 6 partitions.37:create_partitions
call to the controller log leader, but from the log we don't know what the arguments of the call are. An immediate failure response it sent as if there already was the requested number of partitions in the topic.see https://github.com/redpanda-data/redpanda/blob/dev/src/v/kafka/server/handlers/create_partitions.cc#L189-L200
kafka-topics.sh
The text was updated successfully, but these errors were encountered: