Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
Description
During developing different new features, the different protocols have to be kept in a stance where the old client can talk to a new server, and a new client also can talk to an old server.
The latter was solved earlier by exposing the server version in the ServiceInfo, but the prior is a hard thing to deal with.
After a few rounds of discussions we came up with an idea to implement pluggable pre and post validation hooks for request processing, that can help us to either right away reject a specific query from an old client, or if the response contains something that the client can understand, give us the possibility to re-write the regular response to a form that the old client can understand, or at least give the old client a specific error message that says why the request fails.
Similarly, the system should have the possibility to adjust the request coming from the old clients if it is possible, so that the request can be served.
Later on we have identified that there is a specific lifecycle phase, when the cluster is not finalized but already upgraded, certain requests in these cases might need to be right away cancelled, based on some request properties, but just until the new feature is not finalized.
Similarly there is a possibility to write certain things, like auditing, or permission checking as a method plugged into one of the hooks, but this idea was not really battle tested so far, and is not part of the scope at the moment.
Ordering of the plugged in methods are also one thing we might consider later, but was out of scope for the first implementation, though it was kept in mind, and the internal data structure that stores the validation map, should be adjustable to maintain the order later if it becomes necessary.
