strimzi/strimzi-kafka-operator

Description Summary Make the KafkaRoller retry/backoff configurable for cases where a broker is temporarily unsafe to restart. The existing safety checks should remain unchanged. The enhancement is only to allow operators to configure how long KafkaRoller retries before giving up on the current reconciliation. Background This follows the behavior reported in #12649 and discussed in Discussion #12650. In the reported environment: Strimzi 0.40.0 Kafka 3.7.0 9 brokers replication factor 3 min.insync.replicas=2 broker startup/init path can take approximately 5 minutes additional time is required for replica catch-up and ISR re-entry During a Strimzi-managed rolling update, after one broker restarts, the next broker can temporarily be unsafe to restart while replicas from the previous broker are still catching up. KafkaRoller correctly detects this and waits, but currently gives up after the fixed retry sequence: giving up after 10 attempts. Total delay between attempts 127750ms In this

#10188 (comment) revealed that there might be useful metrics that we collect but do not include in the example dashboards. For example, metrics such as kafka_controller_kafkacontroller_fencedbrokercount or kafka_server_replicamanager_offlinereplicacount would be useful metrics to include in the dashboard. This task is to review the metrics mentioned in this comment and consider adding them to the dashboard.

Related problem Currently quotas are applied only on the User, when the need to be more granular by giving each User Client a specific Quota or add a "Default" Quota the Strimzi Operator does not offer this functionality. Suggested solution Ideally the CDR should allow something similar to the following snippet. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: otel-user labels: strimzi.io/cluster: local-cluster spec: authentication: type: tls quotas: producerByteRate: 1048576 consumerByteRate: 2097152 clientQuotas: - producerByteRate: 3333 - clientId: otel-client-id producerByteRate: 4444 consumerByteRate: 2222 requestPercentage: 42 controllerMutationRate: 10 clientQuotas: type: array items: type: object properties: clientId: type: string pattern: ^.

Description The KafkaClusterTest test class is getting too bog and is getting too close to the per-file NCSS checkstyle limit (2000) which cannot be silenced by annotation anymore. We should consider breaking it down along some lines to make it easier to work with and to get within the NCSS limit. (However, as there are some shared fields, we should think about how to do it without too much duplciation)

As described in #12878, we should replace the CompletableFuture with CompletionStage in the APIs (e.g. method return types) of KafkaNodeUnregistration.