Migration to 1.19+

Migration from MACMA Classic to MACMA Core is no longer supported (< 1.16 to 1.18+). If you need to upgrade a pre 1.16.0 environment, please upgrade to 1.16 first to execute Migration from MACMA Classic to MACMA Core.

Otherwise, you will lose data!

Keycloak migrations timeout

The latest migration which enables Keycloak’s dynamic scope feature and assigns the 'aud:*' dynamic scope to all clients may take a lot of time and result in a timeout during Keycloak’s startup. Expect about 1 second per client. The current value for this timeout was set to 1500 seconds which should be more than enough for most environments. In case this is not sufficient, the value can be increased using the following environment variable: KEYCLOAK_MIGRATIONS_TIMEOUT_SECONDS.
Also, liveness, readiness probes or any other health checks for Keycloak container may need their configured time to be increased.
This long-running migration is executed only once, the first time version 1.19 is deployed. Once it is deployed successfully, any changes to the probes/health check timeouts can be reverted to the initial value.

Changed Keycloak environment variables

DB_BG_VALIDATION_MS was replaced with DB_BG_VALIDATION_DURATION (Specify the Duration between liveness-checks for pooled DB connections (optional, default is '55S' as it should not be the same value as idle-timeout(minutes)); the format for durations uses the standard java.time.Duration format. You can learn more about it in the [Duration#parse() javadoc](https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html#parse-java.lang.CharSequence-). Influences failover behavior.)
PROXY_ADDRESS_FORWARDING was replaced with KEYCLOAK_PROXY
When running Keycloak behind a reverse proxy, proxy address forwarding must be enabled. Provide edge, reencrypt or passthrough in order to activate.
The edge value automatically sets http.enabled=true and http.proxy-address-forwarding=true. This mode is suitable for deployments with a highly secure internal network where the reverse proxy keeps a secure connection (HTTP over TLS) with clients while communicating with Keycloak using HTTP.
The reencrypt value automatically sets http.proxy-address-forwarding=true and require the server to be configured with its own pair of keys and certificates so that the HTTPS listener can be properly set. This mode is suitable for deployments where internal communication between the reverse proxy and Keycloak should also be protected where different keys and certificates can be used on the reverse proxy as well as on Keycloak.
The passthrough value automatically sets http.proxy-address-forwarding=true. This mode is suitable for deployments where the reverse proxy is only forwarding the requests to the Keycloak server so that secure connections between the server and clients are based on the keys and certificates used by the Keycloak server itself.
See https://github.com/keycloak/keycloak-community/blob/main/design/keycloak.x/configuration.md for more details about KEYCLOAK_PROXY
KEYCLOAK_MIGRATIONS_TIMEOUT_SECONDS was added (Sets the timeout in seconds, for MACMA’s Keycloak migrations that run at startup)
KEYCLOAK_HA_CACHE_STACK was added: By default, the Keycloak docker image is configured to run in High-Availability mode in a kubernetes environment. In order for this to work a minimum extra configuration is needed: -Djgroups.dns.query=<headless-service-FQDN> needs to be added to JAVA_OPTS_APPEND environment variable
Provide none in order to start a single instance of Keycloak (optional, default is kubernetes). Valid values: none, tcp, udp, kubernetes (see https://www.keycloak.org/server/caching#_transport_stacks for more details)
KEYCLOAK_ALWAYS_HTTPS, KEYCLOAK_SINGLE_INSTANCE were removed

At the moment Keycloak container can run with multiple instances only in a Kubernetes environment (this is a limitation of MACMA’s reverse proxy, not of Keycloak)