[keycloak-dev] Policy around migration-*.cli scripts

Marko Strukelj mstrukel at redhat.com
Thu Sep 14 12:28:53 EDT 2017


I was wondering why migration-*.cli scripts contain migrations for
keycloak-server subsystem.

It makes perfect sense that they are used to adjust configuration of other
wildfly subsystems that we don't control. But for keycloak-server I imagine
all migration should be performed at runtime by keycloak-server subsystem
itself. This way migration is easier to do, it involves fewer modules in
our build, fewer files (no /subsystem=keycloak-server entries in
migration-*.cli files), and it's testable in a single module.

Any reason why not do it that way?

Another thing - currently our (de facto) versioning policy for keycloak
subsystems is to not increment the version as long as the old syntax/model
keeps working, even if we introduce new xml syntax we keep the old version
number.

In practice that means that if I see an example of subsystem configuration
somewhere, and I copy it to the older version of Keycloak (why not, it says
it's still version 1.1) that would not work if it contains any later syntax
that older version doesn't understand. Older keycloak-server configuration
can be copied to newer version of Keycloak without issues.

That's simple for us to maintain, and seems to work well enough.
Technically we'll only have to increment version if we decide to break
backwards compatibility of the configuration - nowhere on our radar ATM.

Does anyone see this policy as problematic?

- marko


More information about the keycloak-dev mailing list