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

On 17 September 2017 at 00:08, Stan Silvert <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> 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. No need to go back further than 1.9.8 (RH-SSO 7.0) 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. Almost? If we could get rid of it completely would that not make migration simpler for users?

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(a)redhat.com <mailto:mstrukel@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(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> >> > _______________________________________________ > 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> _______________________________________________ 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>