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

[Stian Thorgersen]

On 17 September 2017 at 00:08, Stan Silvert <ssilvert at 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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>