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

[Marek Posolda]

I have one thing partially related to this.

There is a JIRA https://issues.jboss.org/browse/KEYCLOAK-5142 . You can 
see my last comment for details, but in shortcut: I've did some changes 
in the migration script, which work fine when they are executed in 
"offline" mode (which is what we describe in the documentation). However 
test doesn't pass as it tests the migration in "online" mode. IMO it 
will be good if the test tests the same steps, which is done by our 
customers. IMO even worse scenario is, if "online" mode works and test 
passes, but "offline" mode is broken.

I wonder if the proposed changes will handle this. It looks to me, that 
they will?

Marek

On 17/09/17 00:08, Stan Silvert wrote:
> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev