Origin: Openshift Route - missing path rewrite feature

[marouim]

Here is my use case:
Front-end application running in a POD.
Back-end running in a différent POD.

Route are:
myapp.example.com/ --> Front-end
myapp.example.com/api --> Back-end

I would like to be able to rewrite the path and remove the "/api" portion, so the Backend would not see this path. Otherwise, I have to tell evey backend developer to add a "/api" or something else prefix to their application.

Just like proxyTable in webpack:

proxyTable: {
'/api': {
target: 'http://localhost:3000',
changeOrigin: true,
pathRewrite: {
'^/api': ''
},
}

Suggestion ===================

````
apiVersion: v1
kind: Route
metadata:
labels:
name: my-app-route
name: my-app-route
spec:
host: my-app.cloudapps.example.com
path: /api/kipos
rewrite: / <======= would be nice to tell reverse proxy to remove the path
port:
targetPort: flaskapi
to:
kind: Service
name: my-app-svc
weight: 100
wildcardPolicy: None
tls:
termination: edge

````

Thanks for your help !

[enj]

@openshift/sig-networking

[openshift-merge-robot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[pmeyer34]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[devops-42]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[devops-42]

/remove-lifecycle stale

[danwinship]

/remove-sig networking
/sig network-edge

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[devops-42]

/remove-lifecycle stale

[Gerrit-K]

I've now seen @marouim 's request at least three times here and two of the issues were closed due to inactivity. I don't understand why this happened, as path rewriting is a quite common thing in web servers.
@ironcladlou can anyone of the openshift team please give a statement on this? Even if it isn't planned in the far future?

[ironcladlou]

IMO it's highly unlikely we're going to expand the Route API in this way. At this point I think we'd actually like to deprecate Route entirely and start converging with the upstream around the proposed Kubernetes Ingress V2 API. You'll find that the rewriting use case is already accounted for there.

I'd recommend becoming familiar with the upstream plans and engaging with us and the emerging community to ensure the plans align with your needs.

All that said, if you want to continue proposing the enhancement to Route, I would recommend opening an OpenShift enhancement proposal to bring the discussion to a resolution one way or another. If the proposal were in extremely close alignment with the Ingress V2 API and if there were someone willing to own the work from start to finish, I think that could increase the chances of acceptance, but that's just my opinion.

[Gerrit-K]

Thank you for the quick and detailed response. The plan to converge to upstream is good news!

[ironcladlou]

I've been thinking about this some more.

The beta v1 Ingress API doesn't support rewriting, but users are loudly encouraged to use vendor annotations. It's clearly useful and we wouldn't be out of alignment with what's being actually used today in the community.

If we have a reasonable confidence of a lossless migration to Ingress v2, what other major risks are there to adding this API?

cc @frobware @Miciah @danehans @knobunc @smarterclayton

[elafontaine]

Could we add this as a annotation like proposed by the upstream kubernetes documentation? I see that haproxy already has a rewrite annotation[1] for 0.10, can't we use the same as we're using haproxy already?

I've been searching way too much around this subject. Where could I find news regarding that design and/or ingress news ? Any way to relaunch the discussion?

[1] https://haproxy-ingress.github.io/docs/configuration/keys/

[sachsenhofer]

I have this issue too.

Something like
haproxy.router.openshift.io/rewrite-target: /
would be helpful.

[benoitf]

I've opened a PR https://github.com/openshift/router/pull/129

There is also an enhancement opened to get this support: https://github.com/openshift/enhancements/pull/287

Documentation: https://github.com/openshift/openshift-docs/pull/22021

haproxy-router image to play with it: quay.io/fbenoit/haproxy-rewrite-annotation:2020.05.12