Giters

jp-gouin / helm-openldap

Helm chart of Openldap in High availability with multi-master replication and PhpLdapAdmin and Ltb-Passwd

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Transactional/Strong consistency possible?

davidfrickert opened this issue · comments

commented

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.

commented

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.

  1. Use a single node openldap , you loose the high availability.
  2. If Keycloak is in the same cluster , use the 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
commented

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!