Details
-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
18.8.0
-
Unknown
-
Description
Upgrading a cluster safely needs the database migrations and the Distribution Wizard to run once, before the members of the new version serve requests, and the upgrade process needs to know whether it worked (for example a Kubernetes Job run before a rolling update). The existing xwiki.store.migration.exitAfterEnd property of xwiki.cfg does not allow it: it stops the JVM with the exit code 0 in the middle of the initialization, before the Distribution Wizard (so pages and extensions are not upgraded, and an empty database is left without any page), and on a failed migration the JVM keeps running.
Proposal: a core.initialization.exitAfterUpgrade property of xwiki.properties (implies the eager initialization of XWIKI-25247) which waits for the initialization, checks the database of every wiki, runs the Distribution Wizard (not interactive) on the main wiki then on every sub-wiki, checks the results (wizard errors, failed extension jobs, installed user interface version), logs a summary and stops the JVM with the exit code 0 (upgraded), 1 (initialization or database failure) or 2 (Distribution Wizard failure). xwiki.store.migration.exitAfterEnd becomes deprecated.
Attachments
Issue Links
- blocks
-
XWIKI-25247 Health endpoint reporting the initialization state, and an option to initialize eagerly at startup
-
- Open
-
-
XWIKI-25297 Prevent several cluster members from migrating the database at the same time
-
- Open
-
-
XWIKI-25298 Refuse to use a database migrated by a more recent version of XWiki
-
- Open
-
- depends on
-
XCOMMONS-3824 Allow waiting for running jobs when XWiki stops and mark interrupted jobs in their stored status
-
- Open
-
- relates to
-
XWIKI-8671 Failing migration on Oracle 10g from 3.5 to 4.4
-
- Closed
-
-
XWIKI-14435 Database update script execution
-
- Open
-