migration guide for 0.13

[ghost]

Confirmations:

• ModeShape Persistence migration guide

• User DB Migration guide

• Elastic Search Migration
  When the new search functionality is merged to prod, it would be useful to have a note in the migration guide, stating the required operation to migrate.

The instructions are already in the search's new Readme.md, but they should also be made more visible in the migration guide.

@aedelmann we started discussing this, but lost track a bit.
I think there are two dependencies here:

• Figuring out what to do with the search integration tests (i.e. access to the machine where they are run and fail due to Allegro not being able to connect to elastic.co). This was in the hands of Tobias last, but I might want to get back in there.
• Taking a decision with regards to the actual release we want for this (12.5 is labeled as "bugfix", so probably not - I wouldn't wait until 1.0 either though?)

[aedelmann]

All the changes will go into the 0.13 release in January, as discussed with Christiane.
This migration guide is for all versions upgrading to 0.13.

[ghost]

@aedelmann @somesh-kumar the branch is here.

I have changed a few things in the migration guide, namely:

• Renamed migration_0.11.md to migration.md to contain all migration steps (also the only reference to it in the release-notes.md)
• Restructured the file headings hierarchy to reflect multiple versions, and added internal anchors where missing
• Added a 0.13 section and a child section about Elasticsearch migration steps

I will now try to troubleshoot the issues with the latest changes with regards to technical user handling, and hopefully somehow come up with documentation about it in the migration guide once I have a better picture on what's going on locally.

[ghost]

Got some progress on the migration script for @erlemantos 's work on the technical users that fails with local dbs.

It's in the early works due to a gazillion extraneous issues stepping in-between but it's slowly taking shape.

For now, I just fixed the null technical user values, which allows me to start vorto locally once again after pulling.

Once I have the SQL I can maybe add it to this task - then we can think of whether it's worth exploring a new IUpgradeTask implementation as Erle suggested.

My idea would be to:

1. Alter the user table and add the technical user boolean if not present
2. Iterate through users and populate authentication providers (if value not already present) at best, i.e. pretty much only Bosch id if username starts with s-... as far as I can tell (note: does anyone know specs for suite auth ids? is there any applicable pattern?)
3. Iterate through users again and set technical user (if value not already present) based on authentication provider

Any thoughts?

[somesh-kumar]

Added ModeShape Persistence migration guide.

[somesh-kumar]

@mena-bosch can you please check the checkbox for Modeshape Guide for me, thanks a lot.

[ghost]

@somesh-kumar thanks for that! Not sure I can really be of much help with that item (which is the reason why I didn't do it myself in the first place) but I'll take a look shortly.

[ghost]

@somesh-kumar sorry it took me so long, I was side-tracked coding for 2088. Your changes look good to me, although I'm not the expert (maybe @erlemantos will want to comment too when he's back?).

[somesh-kumar]

@mena-bosch since you and @aedelmann (4-eyes) have already gone through the changes lets consider it ready for merge.

[somesh-kumar]

What do we need for the remaining section "User DB Migration guide"?

[ghost]

What do we need for the remaining section "User DB Migration guide"?

@somesh-kumar Not sure.
I thought Erle could shed some light there, if anything was needed.

The only concrete issue I recall was with the Maven dependencies (needed to inject a specific Lucene version in one of the poms to avoid a version clash between ES and Modeshape).

However, I cannot remember any specific operation to perform at DB level.

@erlemantos thoughts?

[erlemantos]

@mena-bosch @somesh-kumar I can't see anything more that needs to be done except maybe for the removal of extraneous columns that we are not using anymore (authenticationProvider in User table. We renamed it to authenticationProviderId. Having both could be confusing to people looking at our table structure).

[ghost]

@erlemantos fair point. I can add a conditional removal if exists in the scripts I suppose.

[ghost]

PR for additional migration script refinement here.
Will close this once latest merged.

[ghost]

#2220 merged. Closing.