Enhance OpenLibertyApplication.route to allow configuration of multiple paths for the application

[hhue13]

Feature Request

Currently the OpenLibertyApplication.spec.route YAML key provides the sub-key path to specify a path (or context root or endpoint) to be handled by the OpenShift route generated by the OpenLiberty operator. This is a limitation if the application deployed by the container exposes multiple context roots which should be selectively exposed to external requests (specifying "/" serves all context roots as per OpenShift Route CRD, ).
This limitation is hit for example if the mpMetrics module is configured with exposes the /metrics endpoint as well as the application's context root whereby the /metrics endpoint is usually not supposed to be available via the route but be accessed via the ServiceMonitor only.
Another scenario when this limitation to one path for OpenLibertyApplication.spec.route is a problem is if for example an .ear file is deployed to the container which contains multiple modules where each module serves a specific context root and some should only be used for internal access while others should be served from the internet.

Is your feature request related to a generic (non-Open Liberty) problem?

No

Is your feature request related to a problem?

No

Describe the solution you'd like

A possible solution to this problem would be to enhance the OpenLibertyApplication.route so that multiple path statements can be configured. With the current version of the OpenLiberty operator at the time of writing this issue (1.6.0) the route is configured for example like this:

apiVersion: apps.openliberty.io/v1
kind: OpenLibertyApplication
metadata:
  annotations:
    openliberty.io/day2operations: OpenLibertyTrace,OpenLibertyDump
  labels:
    app-type: OpenLibertyApplication
    application: bedzvp
  name: bedzvp
  namespace: bedzvp-app-f-p0
spec:
:
  expose: true
  route:
    annotations:
      haproxy.router.openshift.io/ip_whitelist: >-
        192.168.1.0/24 192.168.7.0/24
    certificateSecretRef: e-bedzvp-certificate
    host: e-bedzvp.cloud.intern.dir
    path: /
:

and a potential enhancement could look like the following:

apiVersion: apps.openliberty.io/v1
kind: OpenLibertyApplication
metadata:
  annotations:
    openliberty.io/day2operations: OpenLibertyTrace,OpenLibertyDump
  labels:
    app-type: OpenLibertyApplication
    application: bedzvp
  name: bedzvp
  namespace: bedzvp-app-f-p0
spec:
  expose: true
  route:
    annotations:
      haproxy.router.openshift.io/ip_whitelist: >-
        192.168.1.0/24 192.168.7.0/24
    certificateSecretRef: e-bedzvp-certificate
    host: e-bedzvp.cloud.intern.dir
    paths:
      - path: /mod01 
        host: e-mod01-bedzvp.cloud.intern.dir
        certificateSecretRef: e-mod01-bedzvp-certificate
        annotations:
          haproxy.router.openshift.io/ip_whitelist: >-
            192.168.100.0/24 192.168.107.0/24
      - path: /mod02
        host: e-mod02-bedzvp.cloud.intern.dir
      - path: /mod03 

So in this case the OpenLiberty operator shouls create three routes namely

• one route with the context root /mod01 with the attributes path, host, certificateSecretRef, annotations a specified in the first list element of the routes key.
• one route with the context root /mod02 with the host name set to e-mod02-bedzvp.cloud.intern.dir. The certificateSecretRef and annotations should taken from the .spec.route key.
• one route with the context root /mod03 with all attributes taken from the .spec.route key.