Keycloak is in CrashLoopBackOff state

A lot of CI run have been stopped due to a problem with Keycloak

Keycloak Kustomization status:

sylva-system	keycloak  health check failed after 23.914716ms: failed early due to stalled resources: [StatefulSet/keycloak/keycloak status: 'Failed']

Keycloack-0 pod status:

keycloak                           keycloak-0                                                                 0/1     CrashLoopBackOff   11 (5m9s ago)   39m     100.72.234.223   mgmt-1586600036-rke2-capm3-virt-management-cp-1   <none>           <none>

Keycloak-o logs :

2024-12-12 22:48:29,330 WARN  [io.agroal.pool] (agroal-11) Datasource '<default>': FATAL: database "app" does not exist
2024-12-12 22:48:29,332 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (JPA Startup Thread) SQL Error: 0, SQLState: 3D000
2024-12-12 22:48:29,332 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (JPA Startup Thread) FATAL: database "app" does not exist
2024-12-12 22:48:29,333 WARN  [org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator] (JPA Startup Thread) HHH000342: Could not obtain connection to query metadata: org.hibernate.exception.GenericJDBCException: unable to obtain isolated JDBC connection [FATAL: database "app" does not exist] [n/a]
	at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:63)
	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:108

All this behavior seems related to the recent merge of !3308 (merged) (we probably didn't see the problem because the MR was tested with the “upgrade” label.it's a limitation of our CI that will soon be solved)

Assignee Loading
Time tracking Loading