I agree with Marko about WildFly to WildFly migration. It would be
possible for the migration scripts to check the WildFly version though.
Maybe that should be added?
Vlasta, the current migration test has an important overarching
purpose. That is, it can tell if someone changed the config files
(standlone.xml, etc.) without updating the migration scripts.
I suspect that most developers on our team don't think about the
migration scripts much (if they even know about them). So it would be
easy for migration to get out of sync with configs. No matter what you
do to the tests, please keep this sanity check intact.
On 10/10/2017 6:26 AM, 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(a)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
> [2]
https://github.com/wildfly/wildfly-server-migration/releases
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev