Creating an Ingress for the Management UI in a RabbitmqCluster spec

[yannayh]

Currently, in order to access a cluster's management UI we have to use a temporary port forward, which makes it problematic to have a consistent way to access the UI.

It would be great if we could define an ingress within the RabbitmqCluster spec, which will create an ingress forwarding to the cluster's management UI.

[Zerpet]

I think it would be nice to have some automation around the creation of an Ingress, however I do not want to embed the entire Ingress spec in the RabbitmqCluster. It can be interesting to generate an ingress with the name of the RabbitmqCluster name and -rabbitmq suffix, with a rule to match prefix $rabbitmqClusterName + "-rabbitmq", and automagically set the backend Service to the same Service we create.

I think something like this in RabbitmqCluster spec:

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: hello-world
spec:
  ingress:
    ingressClassName: my-ingress-class
    annotations:
      some/annotation: foo-bar

Resulting in the creation of an Ingress in these lines:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-rabbitmq
  annotations:
    some/annotation: foo-bar
spec:
  ingressClassName: my-ingress-class
  rules:
  - http:
      paths:
      - path: /hello-world-rabbitmq
        pathType: Prefix
        backend:
          service:
            name: hello-world
            port:
              number: 15672

There are some caveats in the UX: the user needs to know their Ingress IP or DNS. It's not easy to observe (monitor) and troubleshoot a misconfigured Ingress.

[yannayh]

I agree, I think that the ingressHost should be optionally specified, and will be used if specified.
Maybe secretName aswell?

[Zerpet]

secretName as well could be interesting. I haven't thought too much about TLS in this case yet, mostly because the different scenarios e.g. TLS termination at Ingress, TLS without termination, different certs for AMQP than for Ingress, to name a few, can become very complex quickly. We can start thinking about those when we agree to go ahead with this feature.

The team received the idea positively, but we still have to do some exploring to determine the effort to build this feature.

[github-actions]

This issue has been marked as stale due to 60 days of inactivity. Stale issues will be closed after a further 30 days of inactivity; please remove the stale label in order to prevent this occurring.

[Zerpet]

I'm not actively working on this, but I think it's a nice feature to have. Perhaps @ikvmw is considering this?