mirror of
https://github.com/kanidm/kanidm.git
synced 2025-02-23 20:47:01 +01:00
cb287eeb61
Migrations and server bootstrap are very interconnected processes and in this we'll be addressing and improving both. Server bootstrap was performed by creating base entries in phases, eventually bringing up enough of the *oldest* supported server minimum remigration level, to then allow triggering of migrations. Migrations then applied "patches" effectively ontop of this minimum level to update entries to what they should be in newer versions of the server. This scheme has it's pros and cons, but the major con was that to remove a migration meant squashing it's content back into the minimum remigration level, and this was a human process that was quite error prone and difficult to automate. As well, this scheme also led to cases where the patch migrations would sometimes *not* reflect all the needed changes or content, or in one case was actually undone by a patchlevel fix up that was required to address a bug. Invariably this led to issues, and cases where a new server may have different content to a migrated one - not exactly what we want! This is a new migration scheme that addresses this fragility. However what it trades is verbosity of the content. Rather than having a base set of entries and patching/updating small sections ontop, we have migration data folders that contain the full set of entries as they should appear at that migration level. This makes the bootstrap process easier as we can just apply the migration level as a whole, and targetted to what precise version we want. This also makes migrations more durable as the content is explicitly copied and all entries fully applied, so there is no risk that a migration or data change can be forgotten or applied incorrectly. We are expressing the full state of what our builtin and provided entries should be. Finally this rips out a number of places where migration data was being used as test case data. Not all of these have been replaced (notably in authsession with Account), but the majority have and have been replaced with clearer use of constants rather than building whole entries just to access the name and throw them away for example. |
||
|---|---|---|
| .. | ||
| core | ||
| daemon | ||
| lib | ||
| lib-macros | ||
| testkit | ||
| testkit-macros | ||
| builder.sh | ||
| Dockerfile | ||