Changes for page Simpler Upgrade (9.x)

Last modified by Vincent Massol on 2024/02/26 17:53

<
From version < 1.2 >
edited by Ecaterina Moraru (Valica)
on 2018/09/20 11:03
To version < 1.4 >
edited by Ecaterina Moraru (Valica)
on 2018/09/20 11:19
>
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -2,3 +2,40 @@
2 2  
3 3  Requirement: investigate how we could make the upgrade experience simpler
4 4  
5 +Problems:
6 +* File system configs that need to applied
7 +* If extension pages have been modified the DW process can be a lengthy and advanced process in order to do the merging
8 +* The upgrade usually is done externally (not from the running application), while the server is offline. It is very complicated to upgrade the system while it's running
9 +* Some upgrade steps might differ depending on the OS
10 +
11 +== Improvements ==
12 +
13 +* We can improve the documentation for each of the OS and types of upgrades
14 +* UI:
15 +** Notify the Administrator that a new version is available (use Notifications system)
16 +** Have a dedicated Administration section (either in EM or in the main category) where the Admin can see the current version of XWiki (since the footer info might be modified), and in case there is a newer version, have an "Upgrade" button
17 +*** Propose also some buttons to "Backup" the content / database
18 +*** If hitting on that button the wikis is put in a read-only mode
19 +*** the user is presented with a "loading animation". In case the user would refresh the page, he would see that the server is actually off-line. This "Upgrade" button actually launches an upgrade process/type
20 +*** After some time propose the user to restart the server (similar to what browsers do when upgrading)
21 +
22 +== Ideas ==
23 +
24 +=== Core EM ===
25 +
26 +Have a Core EM, much simpler that is running all the time in the background. When upgrading, just upgrade the UI and the extensions.
27 +The problem with this approach is that it's not solving the whole problem, just partially (like 80%), plus it might need a lot of rewriting of the code.
28 +The Administrator would still need to run the manual upgrade on the Core EM, but at least this would be done on the cycle, so once a year. This would improve the upgrades between minor versions (10.1 to 10.10) of the cycle. This would mean a partial upgrade, but it would bring UI changes faster.
29 +
30 +=== OS Process ===
31 +
32 +When hitting the "Upgrade" button, depending on the OS, a series of scripts will be launched that they will perform all the manual needed tasks.
33 +The problem with this approach is that it's OS dependant. Not sure if there is a solution for Windows, but this would be much simpler to realise on Debian or on OS that have RPM as a package manager (Fedora, Gento).
34 +
35 +=== Cloning ===
36 +
37 +Would be nice to be able for the webapp to clone it self and do the upgrade process in a separate thread / process, while in the same container. The clone could restart itself, do all the checks, validate the success of the upgrade; and if successful, just replace the instances. Still problematic since the webapp might not be able to interact between them, also apparently we still need a Tomcat restart in order for the upgrade to run correctly.
38 +
39 +=== XWiki Runtime ===
40 +
41 +Another component that it's only job is to handle the upgrade processes of EM.

Get Connected