ansible-middleware/keycloak

keycloak_quarkus: Infinispan settings

hwo-wd opened this issue · 5 comments

So I've been experiencing weird RHBK behavior which, after some trial and error, could only really stem from Infinispan.
Checking the configuration I've noticed that:

  • keycloak <v221 used Quarkus <v3, where using quarkus.infinispan-client.server-list in the quarkus.properties file was just fine, however:
  • keycloak >= v22, and thus RHBK, upgraded to Quarkus v3 (3.2.6 in case of RHBK) said setting is no more, since it has been replaced by quarkus.infinispan-client.hosts

@guidograzioli I presume you want to be compatible with Keycloak <v22, right?
Meanwhile, I'll start to work on a fix

Footnotes

  1. https://www.keycloak.org/docs/latest/release_notes/#upgrade-to-quarkus-3-x

Seems similar to #146

Actually the next work in the roadmap, is to provide integration between rhbk and datagrid in preparation of active/active ha; so any change required in infinispan/datagrid + any change for rhbk. Since rhbk is keycloak >= 22.0.6, my focus is to be compatible with >= 22.0.6, but any effort to keep compatibility with 19<=version<=22 is welcomed.

Actually the next work in the roadmap, is to provide integration between rhbk and datagrid in preparation of active/active ha;

so basically templating cache-ispn.xml and checking whether keycloak_quarkus_ha_enabled is set and if so, set the tcpping hosts according to the current inventory, correct?
Is this WIP already, or is it "planned"? cause it's pretty much the next thing on my roadmap (albeit, w/o external dg).

starting reference: https://keycloak.discourse.group/t/infinispan-tcpping-discovery-in-quarkus-distribution/15375/4

It's not started; on legacy keycloak we had JDBC_PING as default discovery, but I'd switch to TCPPING and initial hosts because it is more reliable. If you wish to start on keyclock with embedded infinispan you are welcome since my work will focus on having infinispan external, in preparation of active/active setups.

I'll work on TCPPING, shouldn't be hard; anyway, #157 tests look ok, so we can let this go into main