Simpler Upgrade (9.x)

Last modified by Ecaterina Moraru (Valica) on 2019/05/15 15:42

 Design
 Idea
  • Open XWIKI-14666 Notify administrators when a new version of the platform is available
  • Open XWIKI-8321 Let the user know when a newer extension version is available
 
 

Description

Requirement:  investigate how we could make the upgrade experience simpler

Problems: 

  • File system configs that need to applied
  • If extension pages have been modified the DW process can be a lengthy and advanced process in order to do the merging
  • 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
  • Some upgrade steps might differ depending on the OS

Ideas - Documentation

  • We can improve the documentation for each of the OS and types of upgrades

Ideas - UI

Notifications

  • Notify the Administrator that a new version is available (use Notifications system)

Extensions - Updater

  • 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
  • Separate the Upgrade mechanism in Distribution and Extensions
  • Propose also some buttons to "Backup" the content / database
  • If hitting on that button the wikis is put in a read-only mode
  • 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
  • After some time, propose the user to restart the server (similar to what browsers do when upgrading)

Before

After

Ideas - Implementation

A. Core EM

Have a Core EM, much simpler that is running all the time in the background. When upgrading, just upgrade the UI and the extensions.
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.
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.

B. OS Scripts

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.
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, Gentoo). 

C. Cloning

Would be nice to be able for the webapp to clone itself 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. 

D. XWiki Runtime

Another component that it's only job is to handle the upgrade processes of EM...


 


Related proposals

per page of Page
Type Status
The environment prevents the table from loading data.
 
Page

Tags:
Created by Ecaterina Moraru (Valica) on 2018/09/20 11:01
    

Get Connected