I used the open source helm chart from Confluent: https://github.com/confluentinc/cp-helm-charts/tree/v5.4.0/charts/cp-schema-registry

The heap settings and resource limits were not sufficient for the 5.4.0 release (I need to send in a patch for this and other issues).

## Schema registry JVM Heap Option

heapOptions: "-Xms1000M -Xmx1000M"

resources:

  limits:

   memory: 2Gi

Otherwise, don't forget to specify the your Kafka bootstrap endpoint:

kafka:

  bootstrapServers: "Xx-Kafka-bootstrap....:9092"

On Wed, Feb 12, 2020 at 1:51 PM alonn <alonisser@...> wrote:
>
> Thanks, Yes, I'm trying with multiple instances. I can do with one, probably if that works
> Can you please provide a sample deployment.yaml ? so I can see what I'm missing? 
> Tech blog:https://medium.com/@alonisser
> Personal Blog:degeladom.wordpress.com
> Tel:972-54-6734469
> Email: alonisser@...
>
>
>
> On Wed, Feb 12, 2020 at 7:51 PM Matthew Isaacs <matthew.isaacs@...> wrote:
>>
>> I'm running the Schema Registry service along side a Strimzi deployed Kafka. It seems to be working fine for me. Are you trying to run multiple instances of the the schema registry? I'm afraid I don't fully understand what problem you're having.

I've setup the most basic kafka persistent setup (see the crd below)
But can't seem to understand how to run schema registy against it (with kafka based leader selection)
I see kafka logs with endless generations like this one
Preparing to rebalance group schema-registry in state PreparingRebalance with old generation 24
So it does seem to actually connect , but then something goes wrong

Using bootstrap servers leading to the kafka service 9092 port

The kafka crd

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: "internal-kafka"
spec:
  kafka:
    version: 2.4.0
    replicas: 1
    listeners:
      plain: {}
      tls: {}
    config:
      offsets.topic.replication.factor: 1
      transaction.state.log.replication.factor: 1
      transaction.state.log.min.isr: 1
      log.message.format.version: "2.4"
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        class: managed-premium
        deleteClaim: false
  zookeeper:
    replicas: 1
    storage:
      type: persistent-claim
      size: 100Gi
      class: managed-premium
      deleteClaim: false
  entityOperator:
    topicOperator: {}
    userOperator: {}