You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
its me again... sorry for bringing this issue up again. Basically its the same as described already here: #77
I've made a mistake with my tests back then.
I didnt verify if the migrations executed were persisted as attribute, in fact they were not! So subsequent runs would break because of that.
Currently, if one just executes the migrations they wont be persistent. To persist these one needs to add following migration (at least this is the only fix I found)
If this is the first migration everything is fine. I would propose that this shouldnt be necessary and be performed transparently on default, since this was the default behaviour back then and maybe introduce a flag for disabling this behaviour.
Why is this an issue? I would argue one not familiar with this issue would not understand why nothing gets persisted. Also this is an issue when you have to support two usecases:
boostrapping a new KC24+
migrating a running KC23 to KC24+
If one needs to bootstrap, one can add the migration above but if one upgrades KC23 to a newer version there is a conflict since the migration needs to be at the very first and if there are already migrations and on uses --correct-hashes another issue occurs, which I will detail in another issue regarding --correct-hashes.
Currently my workaround is pretty ugly, I have a separate migration file just executing the very first migration. Which is troublesome since it will crash on many scenarios and this crash must be ignored. There is no way I can determine beforehand if it is necessary or not. Running stock KC image as unmutable container in k8s.
I would argue that enabling "ADMIN_EDIT" on default would be the best solution, since it reflects the old behaviour and lets new users use migrations more easely. For usecases where this is not preferred we should add a command line flag to disable this behaviour.
The text was updated successfully, but these errors were encountered:
So the ADMIN_EDIT could be a thing keycloakmigration does on its own without requiring a migration file at all. So like a new command line option to force ADMIN_EDIT to be active first?
Hello,
its me again... sorry for bringing this issue up again. Basically its the same as described already here: #77
I've made a mistake with my tests back then.
I didnt verify if the migrations executed were persisted as attribute, in fact they were not! So subsequent runs would break because of that.
Currently, if one just executes the migrations they wont be persistent. To persist these one needs to add following migration (at least this is the only fix I found)
If this is the first migration everything is fine. I would propose that this shouldnt be necessary and be performed transparently on default, since this was the default behaviour back then and maybe introduce a flag for disabling this behaviour.
Why is this an issue? I would argue one not familiar with this issue would not understand why nothing gets persisted. Also this is an issue when you have to support two usecases:
If one needs to bootstrap, one can add the migration above but if one upgrades KC23 to a newer version there is a conflict since the migration needs to be at the very first and if there are already migrations and on uses
--correct-hashes
another issue occurs, which I will detail in another issue regarding--correct-hashes
.Currently my workaround is pretty ugly, I have a separate migration file just executing the very first migration. Which is troublesome since it will crash on many scenarios and this crash must be ignored. There is no way I can determine beforehand if it is necessary or not. Running stock KC image as unmutable container in k8s.
I would argue that enabling "ADMIN_EDIT" on default would be the best solution, since it reflects the old behaviour and lets new users use migrations more easely. For usecases where this is not preferred we should add a command line flag to disable this behaviour.
The text was updated successfully, but these errors were encountered: