Changes for page Simpler Upgrade (9.x)

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -19,8 +19,12 @@
19	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	20	*** After some time propose the user to restart the server (similar to what browsers do when upgrading)
21	21
	22	+(%class="row"%)(((
	23	+(%class="col-xs-12 col-sm-3"%)(((
22	22	== Ideas ==
	25	+)))
23	23
	27	+(%class="col-xs-12 col-sm-3"%)(((
24	24	=== Core EM ===
25	25
26	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,15 +27,31 @@
27	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	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	29
	34	+)))
	35	+
	36	+(%class="col-xs-12 col-sm-3"%)(((
30	30	=== OS Process ===
31	31
32	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).
	40	+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).
	41	+)))
34	34
	43	+(%class="col-xs-12 col-sm-3"%)(((
35	35	=== Cloning ===
36	36
37	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	38
	48	+)))
	49	+
	50	+(%class="col-xs-12 col-sm-3"%)(((
39	39	=== XWiki Runtime ===
40	40
41	41	Another component that it's only job is to handle the upgrade processes of EM.
	54	+)))
	55	+)))
	56	+
	57	+
	58	+
	59	+
	60	+
	61	+