Support OpenShift Routes as an alternative to Kubernetes Ingresses

[sergkudinov]

In OpenShift clusters, Routes are preferable to Kubernetes Ingresses. When running Onyxia on OpenShift clusters, it requires Routes configuration as an alternative to Ingresses.

I am suggesting providing Routes configuration for all the Onyxia services' charts of the services that expose the URL to the outside of the cluster.

Implementation steps

1. In the region configuration, add support of OpenShift in the property regions.services.type with the new value OPENSHIFT.
2. In the values.schema.json files, move ingress configuration to the inside of networking (see example config).
3. Add a hidden route configuration similar to ingress.
4. Add choosing between ingress or routes for Onyxia users, defaulting to ingress. It can be a radio button on the interface. It must appear when regions.services.type is OPENSHIFT (this condition is useful because Kubernetes clusters can't use OpenShift Routes, according to my quick research). The interface example is here:
   
5. Make the corresponding changes to chart values and templates providing templates for routes.

Questions

• Can 2 different regions be used by a single user? If yes, how the Onyxa admin choses between them when launching a service? The question is related to the conditional networking described above.

[fcomte]

do you want that a user can choose between ingress and route ?
It seems that the choice should never appear to the end user...

There is some code to do in the API to analyse the route manifest and give all urls to the end users.

[fcomte]

For regions :

It's not possible to select the regions in the web ui at the moment. But we will add that.
We want that a user can select a region in the UI

And maybe after providing some tools to help users to manage data across that two regions.

[sergkudinov]

Indeed, we can fully delegate this to kubernetes cluster admins. Probably somewhere in the regions configuration.

[fcomte]

Yes i guess choosing between route or ingress is more an admin business.
Users should not see that in most case.

[sergkudinov]

In that case, I suggest adding the property regions.services.expose.type with possible values ingress and route.

Should we protect somehow setting this value to route when regions.services.type is KUBERNETES?

[fcomte]

regions.services.type was used to separate KUBERNETES and MARATHON (mesos) containers.

I think we can only use regions.services.expose.type

[fcomte]

You talk about admins where we talk about users.
Do you mean that a onyxia user is an admin ?

[sergkudinov]

corrected to users