KafkaTopics without replicas configuration not getting ready

[Sennahoi]

Hi. I'd like to pre-define the number of replicas for KafkaTopics. Documentation mentions that replicas default to the setting default.replication.factor. but when I create a KafkaTopic without the replicas config, the topic stays unready. I can't find anything in the logs: Nothing in the entitys-operator log, nothing in k8s events, nothing inside the KafkaTopic resource. I also changed the entitiy-operator's log level to DEBUG and still couldn't find a log entry about the missing topic.
Any ideas?

[scholzj]

You should probably share more details:

• Version of Strimzi
• Your full Kafka custom resource
• Your full KafkaTopic custom resource
• Topic Operator logs
• etc.

[Sennahoi]

Strimzi version = 0.33.2
Kafka resource:

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  annotations:
    meta.helm.sh/release-name: wedev-strimzi-kafka
    meta.helm.sh/release-namespace: wedev
  creationTimestamp: "2023-02-10T11:40:46Z"
  generation: 5
  labels:
    app.kubernetes.io/managed-by: Helm
  name: wiq
  namespace: wedev
  resourceVersion: "62908735"
  uid: 9c3e1815-afdd-4c06-9911-913283be7d5f
spec:
  entityOperator:
    topicOperator:
      logging:
        loggers:
          rootLogger.level: DEBUG
        type: inline
    userOperator: {}
  kafka:
    authorization:
      type: simple
    config:
      auto.create.topics.enable: false
      default.replication.factor: 3
      delete.topic.enable: true
      min.insync.replicas: 2
      offsets.topic.replication.factor: 3
      transaction.state.log.min.isr: 1
      transaction.state.log.replication.factor: 3
    listeners:
    - authentication:
        type: scram-sha-512
      name: internal
      port: 9092
      tls: false
      type: internal
    - authentication:
        type: tls
      name: mtls
      port: 9093
      tls: true
      type: internal
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          key: kafka-metrics-config.yml
          name: kafka-metrics
    replicas: 3
    storage:
      class: managed-premium
      deleteClaim: false
      size: 100Gi
      type: persistent-claim
  zookeeper:
    replicas: 3
    storage:
      class: managed-premium
      deleteClaim: false
      size: 10Gi
      type: persistent-claim
status:
  clusterId: UBiUNNbXRu6rGCM9sGwegg
  conditions:
  - lastTransitionTime: "2023-05-02T13:41:35.572500972Z"
    status: "True"
    type: Ready
  listeners:
  - addresses:
    - host: wiq-kafka-bootstrap.wedev.svc
      port: 9092
    bootstrapServers: wiq-kafka-bootstrap.wedev.svc:9092
    name: internal
    type: internal
  - addresses:
    - host: wiq-kafka-bootstrap.wedev.svc
      port: 9093
    bootstrapServers: wiq-kafka-bootstrap.wedev.svc:9093
    certificates:

Kafka topic resource:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"kafka.strimzi.io/v1beta2","config":null,"kind":"KafkaTopic","metadata":{"annotations":{},"labels":{"strimzi.io/cluster":"wiq"},"name":"test-topic6","namespace":"wedev","replicas":null}}
  creationTimestamp: "2023-05-02T13:28:16Z"
  generation: 1
  labels:
    strimzi.io/cluster: wiq
  name: test-topic6
  namespace: wedev
  resourceVersion: "62904704"
  uid: d6860bc9-ffa7-4379-a249-caddad2bd0c4

I attached the entity operator log.
entitiy_operator.log

[scholzj]

You need to specify at least an empty spec section ... e.g.:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  labels:
    strimzi.io/cluster: my-cluster
  name: test-topic6
spec: {}

I will open an issue to throw at least a warning when the .spec section is missing and not ignore it silently.

[scholzj]

Note. I created #8465

[Sennahoi]

Cool! Thanks that you found the solution why this wasn't working. Could I suggest to just accept a KakfaTopic without a spec block? Because having {} feels pretty similar to omitting the spec section altogether.

[scholzj]

TBH, I'm not sure we should do that. The .spec section should have been IMHO required and we should aim for making it required in the next API version (as we cannot just change it now due to backwards compatibility reasons in the CRD schema).