Current
 
Right now creating external connectivity for the public endpoints is done in each service operator, with route and metallb LoadBalancer service.
Usually configure the ingress to an k8s/OCP service is a manual user/admin task. Since we have a lot of OSP services this is automated in the operators.
 
Proposed change
 
For ease of maintainability and enhancement the ingress configuration (route) will be done in a single place, the openstack-operator as the component which brings the OSP product together. Also it will override the service config to be a LoadBalancer service instead of default ClusterIP.

This has the advantage that the service operators would only use k8s native and no OCP specific resource type, like the route. In addition changing or enhance the product for a different kind of ingress  (e.g. gatewayapi or any other) would be a change in a single place, the openstack-operator, for all services.

With this change

• the service operators per default will only create "default" `ClusterIP` service for the endpoint.
• the openstack-operator will
  • create the required routes for components of each service (api, vnc proxy, ...)
  • create the service override for metallb loadbalancer services for the internal endpoints when network isolation is used.
  • The service operator will have parameter for the public endpoint url to register in keystone. If none provided the service url is used.

For standalone usage of the service operators, the route and service override have to be created/provided by the user (doc).

CRD changes
 
Each service operator will have parameters:

• `publicEndpointURL` - public endpoint URL used to register the service in keystone
• `serviceOverride` type struct - analog to the routeOverride proposed in [1]. This aligns with how the rabbitmq operator works [2].
   

[1]https://github.com/openstack-k8s-operators/keystone-operator/pull/269 

[2]https://github.com/rabbitmq/cluster-operator/blob/main/api/v1beta1/rabbitmqcluster_types.go#L174