CFK deployment of Schema R prefix setting appears to be ignored

Schema Registry
1

Hi

I am observing an issue when attempting to deploy version 8.0.0 of Schema registry on an OpenShift system where Confluent is deployed via the CFK operator

What seems to be happening is if you define a value in the spec for the loadbalancer service the value defined via the prefix property is ignored

For example this is an snippet of my yaml for Schema Registry

externalAccess:

loadbalancer:

domain: srv1-text.example.com

prefix: schema-xy-1234

Now what i expected to happen is that the hostaname to be used for SR would be prefix-domain so in the example above schema-xy-1234.srv1-text.example.com BUT what actually gets created is schemaregistry.srv1-text.example.com

This causes an issue as we have a validator that doesn’t allow the created pattern.

It seems the value of prefix is ignored

I have seen similar behaviour with connect 8.0.0

I have tried to see if this is a known issue in the docs with no luck and so any input would be appreciated

2

Does the following work?

externalAccess:
  type: loadBalancer
  loadBalancer:
    domain: <DOMAIN>
    prefix: <PREFIX>

This seems to be working in a quick test on my end – if I run kubectl describe svc schemaregistry-bootstrap-lb I see this in output:

Annotations: external-dns.alpha.kubernetes.io/hostname: <PREFIX>.<DOMAIN>

Which docs are you looking at? I used this reference.

3

Hi,

Firstly thanks for the prompt response

Yes i am using those options in the spec ,which i discovered by using an oc explain on the component

Its good to see that in your test the value of prefix was adhered to as in my tests it wasn’t as in my tests its gets ignored

So the question then is what is different between your test and mine?

I am using tag 8.0.0 of the schema registry image and the tag of my CFK operator image is 0.1263.8 and the schemaregistry CRD reports app version 3.0.1

4

Can you paste in your entire spec (excluding anything sensitive)? I’ll see if anything jumps out.

5

Hi

I will need to check if i am able to share the spec so leave it with me.

In the meantime could you confirm the versions of CRD and Operator plus Schema Reg image you used in your successful test ?

Could you add your spec here ?

6

This example uses Confluent for Kubernetes 3.1.1, Operator 0.1351.59, and CP 8.1.1:

apiVersion: platform.confluent.io/v1beta1
kind: KRaftController
metadata:
  name: kraftcontroller
  namespace: confluent
spec:
  dataVolumeCapacity: 10G
  image:
    application: docker.io/confluentinc/cp-server:8.1.1
    init: confluentinc/confluent-init-container:3.1.1
  replicas: 3
  dependencies:
    metricsClient:
      url: http://controlcenter.confluent.svc.cluster.local:9090
---
apiVersion: platform.confluent.io/v1beta1
kind: Kafka
metadata:
  name: kafka
  namespace: confluent
spec:
  replicas: 3
  image:
    application: confluentinc/cp-server:8.1.1
    init: confluentinc/confluent-init-container:3.1.1
  dataVolumeCapacity: 100Gi
  dependencies:
    kRaftController:
      clusterRef:
        name: kraftcontroller
    metricsClient:
      url: http://controlcenter.confluent.svc.cluster.local:9090
---
apiVersion: platform.confluent.io/v1beta1
kind: SchemaRegistry
metadata:
  name: schemaregistry
  namespace: confluent
spec:
  replicas: 3
  image:
    application: confluentinc/cp-schema-registry:8.1.1
    init: confluentinc/confluent-init-container:3.1.1
  externalAccess:
    type: loadBalancer
    loadBalancer:
      domain: <DOMAIN>
      prefix: <PREFIX>
1 Like
7

Hi Dave

Thank you so much for providing your spec and also your version details as that really helps.

I am actually looking at this issue in a restricted air-gapped environment and so getting the new versions deployed is a challenge but I wonder could i ask a favour which is is there any chance you could do a parallel test of your setup using the versions i have deployed to see if you can reproduce the problem I see.
As what i have in my spec matches your working example / environment.
My versions are schema reg 8.0.0 , operator image is 0.1263.8 and the schemaregistry CRD reports app version 3.0.1

Thanks in advance

8

I get the same expected result with those versions. Can you share the output of kubectl describe svc schemaregistry-bootstrap-lb?

9

Sorry i have been off for a few days
As a matter of interest were your tests running on OpenShift as i am ?