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(a)redhat.com
<mailto:vramik@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/MigrationFromOlde...
<
http://www.keycloak.org/docs/latest/server_admin/topics/MigrationFromOlde...
[2]
https://github.com/wildfly/wildfly-server-migration/releases
<
https://github.com/wildfly/wildfly-server-migration/releases>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<
https://lists.jboss.org/mailman/listinfo/keycloak-dev>