[Enhancement]: Support configuring .spec.subdomain for OpenShift routes

[tim-van-dijkhuizen]

Related problem

I recently started using Strimzi on OpenShift and configured it to create routes for external access. This worked perfectly fine before but now failed due to the generated routes exceeding the maximum DNS host (part) length of 63 characters.

I've searched the Strimzi docs and code trying to find a work-around (see alternatives) but none really fit my setup.

Suggested solution

OpenShift Route resources support setting the .spec.subdomain to define the first part of the host.

Example: If you set subdomain for your route to "test123" and the apps domain for your OpenShift cluster is set to "apps.example.com" the generated host would be test123.apps.example.com.

OpenShift Route specs:
https://docs.okd.io/latest/rest_api/network_apis/route-route-openshift-io-v1.html#spec

It would be great if, just like the "host" property, we could configure the "subdomain" property through the listener configuration block inside my Kafka resource spec.

Example spec:

# ...
listeners:
  # ...
  - name: external
    port: 9094
    type: route
    tls: true
    authentication:
      type: tls
    configuration:
      bootstrap:
        subdomain: my-kafka
      brokers:
      - broker: 0
        subdomain: my-kafka-0
# ...

Alternatives

1. It's possible to define the host to be used for a listener. This is not an option because I'm not using a custom domain but instead the *.apps.example.com managed by OpenShift. This domain is different for each environment, and I would really like to avoid having to define this domain in my Helm Charts values as it changes every now and then.
2. It's possible to create your own route when using listener type cluster-ip. However, once again, I do not know the full host in advance which makes it impossible to add it as alternative subject and therefor the generated certificate won't work for my custom Route.
3. The spec.kafka.template.externalBootstrapRoute propery could have been the solution, but unfortunately it only allows overriding the labels and annotations of the Route.
4. Obviously, I could reduce the length of my namespace or Kafka resource name. This is not my preferred approach as it requires some big changes, and it doesn't feel like a future-proof solution. My namespace and resources names are not extremely long so future resources might face this issue as well. Ideally, I would like more flexible control over the route configuration.

Additional context

No response

[scholzj]

I think there are plenty workarounds (as you already listed yourself), so I don't think we want to support this:

• Name your resources in a way that the domain name does not exceed the characters
• Configure the host used for the Route as already supported
• Use a cluster-ip type listener, configure the advertised host / port and manage your Route resources on your own

All of these are pretty simple and if needed you can surely write some tooling to make sure it uses the correct domain etc.

[tim-van-dijkhuizen]

I think there are plenty workarounds (as you already listed yourself), so I don't think we want to support this:

• Name your resources in a way that the domain name does not exceed the characters
• Configure the host used for the Route as already supported
• Use a cluster-ip type listener, configure the advertised host / port and manage your Route resources on your own

All of these are pretty simple and if needed you can surely write some tooling to make sure it uses the correct domain etc.

This small addition to Strimzi would save me (and others) a lot of time that I would have to spend on automation and maintenance. In my option a tool that creates Kubernetes resources should allow (almost) full customization of the generated resources. So, I hope you'll consider it anyway.

I was thinking about creating a PR, but decided to start off with a feature-request as setting up the development/testing environment for myself would take me way more time than an existing contributor needs to copy-paste the host property implementation and rename it to subdomain (maybe I'm underestimating the work involved) 🙂

[scholzj]

I was thinking about creating a PR, but decided to start off with a feature-request as setting up the development/testing environment for myself would take me way more time than an existing contributor needs to copy-paste the host property implementation and rename it to subdomain (maybe I'm underestimating the work involved) 🙂

The issue will be triaged on one the community calls and that will decide if this feature would be accepted or not. So in general, you should wait with any PRs for that. If we decide that it would be accepted, we would of course welcome the PR from you (and possibly nobody else might do it anyway). As it would involve API changes, it would also likely require a proposal.

This small addition to Strimzi would save me (and others) a lot of time that I would have to spend on automation and maintenance.

It is seemingly a small addition. But it is something like a sixth way to do essentially the same thing. All of these need to be tested, maintained, taken care of in every refactoring, etc.

So the time you would spend on for example writing some super simple Helm Chart to template the host field would be just dumped on the community (and would likely be a much higher in reality). That makes sense when it is feature useful for many people. It does not make sense for every single niche idea someone might have.

Unfortunately, we cannot please everyone - so the aim is to try to create the best path for most people and yet make things flexible enough for the outliers who need something special to be able to handle it as well - those are the workarounds you can use.

In my option a tool that creates Kubernetes resources should allow (almost) full customization of the generated resources. So, I hope you'll consider it anyway.

Every operator that manages Kubernetes resources and something like Kafka will be always opinionated. You might need to accept its opinions if you want to use it.