Closed maleck13 closed 2 years ago
@eguzki @rahulanand16nov I have updated the use cases here to reflect that there are developers who don't care about virtual services and those that are comfortable with them.
Added Kuadrant/kuadrant-controller#119 item. Kind of replacing Kuadrant/kuadrant-controller#103 that is unfeasible
can we close this issue @maleck13 ?
I think we can close it and reopen a new issue if we move to support OS Routes in the future
Use Cases
As a developer familiar with OpenShift Routes, I do not want to have to learn the Istio Specific routing API (VirtualService), I just want to be able protect my service exposed via an OpenShift Route with kuadrant's RateLimiting and Auth capabilities, so that I can protect my APIs as simply as possible and reduce the number of new APIs I need to learn and be familiar with. It is important to me that I declare a route as "kuadrant managed".
As an API developer, familiar with OpenShift routes and Istio, I know I need to use an OpenShift route to expose my service as HAProxy is my entry point to the cluster, but I want to retain control over the VirtualService resource and protect my service with rate limiting and auth. As I am very comfortable with these concepts, I am happy to manage both of these resources myself.
Options
One option here is to support our kuadrant annotations on the OpenShift Route object. We may need an additional annotation to declare whether the Route should be kuadrant managed or not (somewhat similar to declaring you want a cert managed for a route). This new annotation
kuadarant.io/managed: true
would trigger the Kuadrant Controller to generate and setup a VirtualService and update the Route object to point at the Istio Gateway. When the kuadrant controller generates a VirtualService it should also copy over the annotations to the virtual service. This will mean when a user uses kuadrant annotations on a route, we will naturally be watching the virtual service and can use the same logic to do the wiring up. One consideration is where the VirtualService should be created. If it is created in the same namespace then the developer will likely have perms to tinker with it. If we create it in the gateway namespace we will need to be able to map it back to the route and the namespace the route is in so that we can find the RateLimiting policy to applyDemo
Done