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

[Marko Strukelj]

On Mon, Sep 18, 2017 at 3:28 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> 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?
>

The key here is 'for non-keycloak subsystems'. AFAIK these can not be
migrated from within keycloak-server subsystem or maybe their model can be
affected but would trigger reloads of whole subsystems. I would need to
explore that. Even if it worked it would probably only work for standalone,
not for domain? The benefit would be - no need to run migration .cli, the
'bad' thing would be - you couldn't take a look in advance what config
changes are about to be performed, which is something server admins may
place a high value on.