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

[Stan Silvert]

On 9/18/2017 9:28 AM, Stian Thorgersen wrote:
>
>
> On 17 September 2017 at 00:08, Stan Silvert <ssilvert at redhat.com 
> <mailto: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?
I just mean it's technically possible to rewrite parts of non-keycloak 
subsystems to add keycloak default values.  Not something I think we 
would really want to do.
>
>
>     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 <mailto: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 <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>