Should route services really need a route-app mapping?
Currently, a route service is not invoked if the route is not mapped to a Cloud Foundry application.
While I understood that this was a conscious decision taken earlier, I would like to question this now and get your feedback.
A route service is supposed to work on routes and while routes are connected to applications, an application-route mapping may not always be necessary.
For example, there could be third party processes that require access over a Cloud Foundry route. In such cases, deploying a Cloud Foundry application is unnecessary and may not be possible as well.
The route service can forward the request to the third-party endpoint without any interaction with the Cloud Foundry application subsystem at all.
In the current state, the route has to be mapped to an application for the proxying to work, otherwise the route service proxy is not invoked at all.
Do you feel this is a valid ask? And if so, do you see any challenges in this?
We've also had use cases where we wanted to employ a route service on routes which where not bound to any app.
Our current workaround consists of changing DNS entries and bypassing gorouter for those use cases (basically this pattern https://docs.cloudfoundry.org/services/route-services.html#static-brokered).
Although it would definitely be nice if gorouter would just handle those cases as well, if I understood it correctly a route is only emitted to gorouter if an app is bound to it (making unbound routes invisible for it).
Through the darkness of future past
the magician longs to see
One chants out between two worlds
Fire walk with me.
Currently routes are only known to Gorouter when they are mapped to an app AND the app has running instances. If the app is stopped or crashing, Gorouter will return a 404 for the route. This is because routing configuration is passed through the Diego BBS.
We've received requests for this several times in the past; see http://cf-dev.70369.x6.nabble.com/cf-dev-Brokered-route-services-only-receiving-traffic-for-routes-mapped-to-started-apps-td4699.html#a4742.
You may be happy to learn that we plan to support this use case in coming months. However, we will offer it through our integration with Istio Pilot and Envoy; we don't plan on offering it using Gorouter. One of the key differences between the current routing subsystem and our integration with Istio is that Istio will receive routes directly from Cloud Controller, while only backend IPs and ports will be obtained from Diego BBS. This will enable us to have the router (Envoy) be configured with a route that is associated with a route service but not an app. More on our initiative here: https://docs.google.com/document/d/1VldkvgWPUh13o5RCNjSvzoPFhbY9BtLqBDdk2k0z9fw/edit.
Krannich, Bernd <bernd.krannich@...>
Thank you very much for getting back to us on the topic. Quite a few teams here at SAP will be happy to hear about the topic and I’ll make sure to pass your update on to them.
<cf-dev@...> on behalf of Shannon Coen <scoen@...>
[Edited Message Follows]
Currently routes are only known to Gorouter when they are mapped to an app AND the app has running instances. If the app is stopped or crashing, Gorouter will return
a 404 for the route. This is because routing configuration is passed through the Diego BBS.