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

[Stan Silvert]

Marko and I spent a lot of time Friday chatting about it and trying a 
few things.  If anyone wants the gory details I can post the text.

We're not finished, but the summary is that we need to:
1) Make sure the migration test is running properly
2) Work with Tomaz Cerar to find out about his latest API improvements 
for subsystem versioning.
3) Decide if we should start using Tomaz's stuff in the future instead 
of or in addition to the migration scripts.

A big question is how far back do we want to support migration? Right 
now the migration tool for standalone.xml goes back to 1.8. So we are 
supporting migration of standalone.xml for anything forward from that.  
Maybe we don't need to go back that far.

I don't think we will ever get rid of the migration scripts entirely.  
We are (almost) required to use it for non-keycloak subsystems, so it 
kind of makes sense to have migration for our stuff in the same script.

On 9/15/2017 5:26 AM, Stian Thorgersen wrote:
> Stan knows this stuff better than anyone, but I seem to remember there was
> some good reasons for this.
>
> On 14 September 2017 at 18:28, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>> 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
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev