[keycloak-dev] server-config-migration

[Marko Strukelj]

I see, that sounds like the right approach, yes.

On Oct 10, 2017 13:51, "Vlasta Ramik" <vramik at redhat.com> wrote:

> Thanks Marko,
> if I understand correctly changes performed within subsystems are handled
> by the subsystem itself during the first container start (at the latest).
> But changes like removing subsystem should be added as a command to our
> migration script, right?
>
> There is <subsystem xmlns="urn:jboss:domain:jdr:1.0"/> remained after
> migration (and after container start) on my env.
>
> If so, I'll add the command, if not a JIRA should be fired.
>
> On 10/10/2017 12:26 PM, Marko Strukelj wrote:
>
> I've been looking at server-config-migration tests a little so I have some
> thoughts on this.
>
> As a criteria - most elegant solution is for our migration scripts to
> perform the minimum necessary migration operations. I think we only target
> these scripts for keycloak server distribution - not overlay - thus we have
> full knowledge of what Wildfly version is underneath a specific Keycloak
> version, and we can add all the necessary .cli commands to address
> configuration changes due to Wildfly upgrade whould that be necessary. But,
> AFAICT no explicit Wildfly upgrade is necessary because it happens
> automatically in this scenario.
>
> Our migration scripts presume latest Keycloak (not Wildfly) installation.
> And what that means is that you already have all the underlying Wildfly
> updates in place (i.e. modules) because latest Keycloak distribution
> already contains them - except that you overwrite standalone.xml with old
> one like you say. Wildfly subsystems are supposed to take care of their own
> migration as far as configuration goes. Most of the work of
> wildfly-server-migration tool, I believe, is to apply modules changes. Any
> configuration updates as reflected in standalone.xml are delegated to
> subsystems, and if they are not performed by migration tool, or
> automatically by subsystems during offline migration, they are performed
> automatically by subsystems the first time you start migrated Keycloak.
>
> So, I don't think we need to concern ourselves with Wildfly to Wildfly
> migration at all.
>
>
> On Tue, Oct 10, 2017 at 10:44 AM, Vlasta Ramik <vramik at redhat.com> wrote:
>
>> I'm working on rewriting server-config-migration tests. Currently there
>> is used wildfly-maven-plugin which does the migration in online mode,
>> I've redone this using exec plugin and the migration is done in offline
>> mode.
>>
>> My question is how do we should handle changes what are done to
>> standalone.xml (or standalone-ha.xml, etc.) between different versions
>> of wildfly. It is out of keycloak scope, but according to migration
>> guide [1], users are supposed to replace default version (current) of
>> config with previous version.
>>
>> As far as I was able to find out WF uses a tool [2] for migration. There
>> is not migration from WF10 to WF11.
>>
>> Should be it somehow incorporated into our migration scripts?
>>
>> If not then the migration guide should be updated with supported
>> migration steps.
>>
>> [1]
>> http://www.keycloak.org/docs/latest/server_admin/topics/Migr
>> ationFromOlderVersions.html
>> [2] https://github.com/wildfly/wildfly-server-migration/releases
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>