Use `Ingress` as an alternative to `Route`

[jmesnil]

Is your feature request related to a problem? Please describe.

The Helm Chart creates a Route resource to expose the application outside of the OpenShift cluster. However this is an OpenShift-only resource and must be disabled when the chart is installed on another type of Kubernetes clusters.

The Helm Chart should allow to configure an Ingress instead of a Route for such case.

Describe the solution you'd like

Add new fields under deploy.ingress to configure an Ingress resource. This section should be mutually exclusive with the deploy.route fields.

We can add:

• deploy.ingress.enabled -> enables Ingress (false by default)
• deploy.ingress.hostname -> specifies the host (wildfly.local by default?)
• deploy.ingress.path -> specifies the path in the rules (/ by default)

The generated resource would look like something similar to:

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: <app name>
spec:
  rules:
    - host: <deploy.ingress.hostname (wildfly.local by default) >
       http:
        paths:
          - path: <deploy.ingress.path (/ by default) >
            pathType: Prefix
            backend:
              service:
                name: <app name>
                port:
                  number: 8080

[yersan]

There would be more tweaks related to Kubernetes vs OpenShift.

Shouldn't we detect the environment type automatically and perform those tweaks behind scenes? Users would be able to use the same Helm Chart configuration independently of the cluster; if it is running on OpenShift, a route would be created and, if it is running on Kubernetes, then an ingress, and the same for other related configurations. Not sure if that's possible, if not, maybe the user should be able to choose between the mode (Kubernetes/OpenShift) so they have to know only one configuration and the helm chart will work properly upon it.

[jmesnil]

When the app is deployed on OpenShift, it's valid to deploy it with an Ingress only (and OpenShift would automatically generate a Route for that ingress). Please note that helm lookup allows to lookup if resource or kinds exists (https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function). We could lookup if the Route kind exists before creating the resource.

I'm not sure on how to let users determines the configuration vs. using helm lookup to infer which resources should be created on the container platform target.