[keycloak-dev] server-config-migration

[Vlasta Ramik]

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 
> <mailto: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/MigrationFromOlderVersions.html
>     <http://www.keycloak.org/docs/latest/server_admin/topics/MigrationFromOlderVersions.html>
>     [2] https://github.com/wildfly/wildfly-server-migration/releases
>     <https://github.com/wildfly/wildfly-server-migration/releases>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>