Closed davidfrickert closed 4 months ago
Hi @davidfrickert , I don't know if this is possible using only Openldap. Maybe someone here knows better.
In my CI tests I performed a read right after a write and it always works. In your case Keycloak must be doing the read a millisecond after the write.
I see potential alternatives with downside to your issue.
headless service
of openldap-0
in Keycloak federation.
You keep the high availability but in case of failure you have to manually switch to another headless service
Thanks for the quick response @jp-gouin
Yeah from googling around it seemed not possible but just wanted to check. I've opened an issue on the Keycloak side to check if they can e.g. introduce an exponential backoff of some sort. Both of the alternatives are not super viable as there is a very real loss of High Availability. Feel free to close this issue!
Is your feature request related to a problem? Please describe. On the default setup, the cluster is on a Eventual Consistency mode, this means that if a write is performed on replica X and instantly after receiving the write response, a read is performed on replica Y, the new data is not there.
Describe the solution you'd like Would it be possible to ensure Transactional/Strong Consistency? Such that the write response is only returned once the writes have been propagated to all replicas.
Describe alternatives you've considered N/A
Additional context Using Keycloak to federate with OpenLDAP cluster. Keycloak tries to perform a read after creating a new user, which fails if the requests does not hit the same replica that received the write.