| fungi | looks like there's a master realm and no zuul realm, as best i can tell. our zuul.conf expects an issuer_id of https://keycloak.opendev.org/auth/realms/zuul | 00:08 |
|---|---|---|
| fungi | i have a feeling our old data isn't getting mounted correctly into the container | 00:08 |
| fungi | also we'll likely need to change that issuer id to https://keycloak.opendev.org/realms/zuul or redirect auth to / | 00:09 |
| fungi | but one problem at a time | 00:09 |
| fungi | we're mounting in a volume that presents (among other relevant paths) /opt/jboss/keycloak/standalone/data/keycloak.mv.db but there's also a /opt/keycloak/data/h2/keycloakdb.mv.db when i exec a shell in the container and poke around | 00:12 |
| fungi | yeah, looks like keycloak's getting run out of /opt/keycloak/bin inside the container | 00:14 |
| fungi | i'm kinda worried that the database filenames aren't quite identical though | 00:17 |
| fungi | in our tree we have keycloak.mv.db and keycloak.trace.db but what the container is creating is keycloakdb.mv.db and keycloakdb.trace.db (note the extra "db" in the filenames) | 00:18 |
| Clark[m] | Hrm | 00:18 |
| Clark[m] | I guess keycloak hadnt anticipated people migrating from the old to the new images? | 00:19 |
| Clark[m] | It's weird to me that you would change file paths and mount pointe for the framework change | 00:19 |
| fungi | ...maybe? i would have assumed (perhaps incorrectly) that the application would have a default database filename though | 00:20 |
| Clark[m] | I guess part of the issue here is wildfly is jboss and it had/has a bunch of paths specific to it | 00:21 |
| fungi | it's possible if we change our data mount from /opt/jboss/keycloak/standalone/data to /opt/keycloak/data/h2 it will just find the old databases even though the filenames for them differ slightly within those directories | 00:21 |
| Clark[m] | But ya the filename change seems odd | 00:21 |
| Clark[m] | Ya or we rename the files too | 00:21 |
| fungi | that would be... unfortunate | 00:21 |
| fungi | i think we probably ought to tar up a local backup of the directories we're mounting in before we go any further though | 00:22 |
| fungi | just so that if we do end up screwing them up somehow we can wipe and restore them easily | 00:22 |
| fungi | i'll fiddle with it some more tomorrow. presumably we don't need to worry about rolling this back, but i'm happy to push up a revert if that's preferred. i could also test by copying the production data into the held test node, but i have a feeling that will only get us so far and we still won't be able to end-to-end exercise zuul dashboard logins with it that way | 00:24 |
| Clark[m] | https://www.keycloak.org/migration/migrating-to-quarkus doesn't say anything about the db | 00:25 |
| Clark[m] | It does mention the /auth removal | 00:25 |
| fungi | yet another option would be to wipe the data and start over, configuring the zuul realm from scratch and readding users in it. not a fan of the additional work, but i suppose it would be cleaner | 00:26 |
| fungi | more hassle for everyone though | 00:26 |
| Clark[m] | Ya and maybe if we do that evaluate if an H2 db on disk is portable enough for the future | 00:28 |
| Clark[m] | I suspect if we had a db server running alongside this would've just worked (tm) | 00:28 |
| fungi | well, i vaguely recall discussing when the initial poc went up that we might revisit the h2 choice in the future | 00:28 |
| Clark[m] | Because db servers handle upgrades and backward compat | 00:28 |
| fungi | but that because h2 was the baked-in default and required no additional configuration, it was simpler for the initial deployment | 00:29 |
| Clark[m] | Ya and it probably would work to adjust the mounts (and rename files if necessary) | 00:31 |
| fungi | i' | 00:31 |
| fungi | er | 00:32 |
| fungi | i'm also getting confused by discussions i'm finding about memory-backed vs file-backed h2 databases for keycloak. maybe the filename difference is denoting a switch in the default for that? | 00:32 |
| fungi | KEYCLOAK_DATABASE_VENDOR=dev-mem vs KEYCLOAK_DATABASE_VENDOR=dev-file | 00:33 |
| Clark[m] | The db has to be persisted to disk but ya maybe it's a different filename if mem is backed to disk? | 00:33 |
| fungi | right, that's what i'm wondering | 00:33 |
| Clark[m] | https://github.com/keycloak/keycloak/issues/13252 says dev mem is not persisted to disk and you lose the data on restart | 00:34 |
| fungi | there's also KC_DB=dev-mem vs KC_DB=dev-file, hard to tell if that changed between versions as well | 00:34 |
| fungi | okay, and since dev-file is the default and we're not overriding it, then i guess it's also the default in the old-style images | 00:35 |
| fungi | looks like you can use KC_DB_URL to set the database so maybe the value for that changed | 00:36 |
| fungi | like from jdbc:h2:file:keycloak to jdbc:h2:file:keycloakdb | 00:37 |
| Clark[m] | That would explain it | 00:37 |
| fungi | i guess that'll be in a dockerfile somewhere | 00:50 |
| *** diablo_rojo is now known as Guest617 | 19:34 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!