Listener refactoring #75
Description
Current Situation
At the moment the listener contains many, many iterations of different requirements and attempts on how to achieve the result of dynamically providing OpenAPI-Schemas for a set of clusters.
We have the following possible operation modes:
- KCP-Mode: In KCP-Mode we use an apiexport provider from the multicluster-runtime in order to reconcile every cluster, that has a given apibinding and provide an OpenAPI-Schema for it
ClusterAccess-Mode is a mode in which a given resource in a target cluster is reconciled and with the information from that resource, an OpenAPI-Schema is generated
For both Modes we have extended the generated OpenAPI-Schema with additional informations and attributes in order to influence the behaviour of the handler generation in the gateway. We need to ensure to consolidate these attributes, document them properly and do find solutions wherever possible to not use them, if there may be a more standard or better way on how to achieve the same effect.
Also both of these mode do not share a lot of common behaviour at the moment, even though they achieve the same result. We should strive to minimise the amount of code we produce where possible and maximise reuse if possible between the two operating modes.
As both of the modes contain "historically grown" iterations of the solution, we should really try and remove this technical debt and provide a clean solution, that contains valueable logic and not old ballast.
Additionally the current iteration of the listener has a lot of unnecessary interfaces and abstractions that are really not needed (e.g IOHandler, apischeme.Resolver).
We also currently, due to historic incompatibility issues, provide a way to convert between different versions of an OpenAPI-Schema. We should investigate if that is still necessary or we can just use the latest version in both components, the listener and the gateway. Especially since k/k is depracating the v2 endpoint for OpenAPI and focusing on v3.
In general we should heavily reduce the complexity that the listener currently has, since I have the feeling it is not necessary to have such a overly complex component for this relatively straight forward task.
Todos
- Investigate ways on how to maximize (but not force) reuse between the different modes - analyse where they differ, but still consolidate wherever possible with the main goal to simplify what we have
- Document and simplify custom property injection
- Investigate and remove unnecessary abstractions within the listener and minimise nesting and distributing of logic too much.
- Investigate and remove multi-version capability of OpenAPI-Schemas from listener and gateway
- Revisit VirtualWorkspace implementation and reduce complexity
- Anything else that pops up during rewriting the code