Over the last few years we’ve made many changes to improve the reliability of the ownCloud upgrade progress. As part of our efforts, we’ve introduced changes which put more manual work on the shoulders of ownCloud system administrators. The downside was that these made the upgrade process more cumbersome. We’re aware of this and are working hard on creating a robust, yet simple upgrade process.
The first ownCloud releases would upgrade with a simple click on the upgrade button in the web interface. As the default PHP settings on many servers kill long running processes, however, we have recommended running upgrades from the command line. Similarly, the ownCloud packages used to run the upgrade automatically but occasionally, they would be interrupted by system administrators who did not expect a simple
apt-get update; apt-get upgrade to take so long. To avoid this and make sure administrators could be properly informed on the state of the upgrade process (something not supported by all packaging formats), our latest packages no longer perform this step automatically but put the server in maintenance mode and inform the system administrator to run the upgrade by hand.
Another change which happened several releases back was that we decided to disable any custom apps before starting the upgrade process. This creates additional work for the system administrator, who will have to go in after the upgrade has ran to enable each of the apps and step through their individual upgrade process. However, it avoids the ownCloud upgrade process getting interrupted by an incompatible or otherwise problematic app.
With all these changes, we’ve put stability and a working ownCloud server before an easy and quick upgrade procedure and it has been these and other improvements which have made the process of moving to a newer ownCloud version far more robust.
However, we would like our users to not only have a flawless upgrade but also an easy one.
To make the upgrade process smoother, we’re working on a variety of changes. The most important are dealing with apps and the upgrade process itself.
We are working on detecting problems in apps when you enable them and recovering from those. A reliable process for upgrading apps would allow us to bring back an automated step at the end of the upgrade which updates and then re-enables apps.
The upgrade process itself is also getting an overhaul to get to our ideal of smooth upgrades. The goals here are to have an upgrade process which is faster, improves on progress and error reporting, and never leaves the server in a broken state.
A new process
The first major change to the upgrade process is to separate it from the rest of ownCloud. This will avoid the updater shooting itself in the foot by, for example, replacing files it itself depends on during the upgrade process. Second is a redesign of the steps the upgrade app goes through, to ensure we accomplish the goals set.
The new Upgrade tool will go through these steps:
- Run a system health check and give an overview of what will happen
- Backup database/data (optional)
- Database schema upgrade (optional with first a simulation)
- Disable 3rdparty/no shipped apps
- Upgrade core and shipped apps
- Try to re-enable and upgrade 3rdparty/non shipped apps
The first step and following progress overview offers estimations of how long the steps take. Some of these can take quite a while on large installations and it happens that administrators break off the process, thinking something went wrong. This really should be avoided as it needs restoration of a backup to allow for a second run.
The health check looks at available and upgradable versions of ownCloud, dependencies like the right versions of PHP and MySQL, if the right files and folders are writable and so on. This way, we can catch problems before they might happen. Another component here is the brand new code integrity checking and signing, which allows ownCloud to check if any files were modified, or if upgrading missed or failed for some of the files. This helps both stability as well as security. The health check also checks the database to see if it contains manual changes or portions which can’t be upgraded or might not work. Last but not least, the health check informs the administrator what third party apps are enabled and for which of those a new, compatible version is available in the app store.
The backups are important to allow an automatic roll back in case the upgrade was interrupted or encountered problems half-way. Offering an automated backup functionality makes it easy and quick to take this step. Next is moving to the new database scheme. This can first be simulated to ensure a smooth update. We then disable third party apps to avoid interference in the upgrade process and proceed to execute the upgrade.
Once the upgrade of core and core apps has been completed, the updater re-enables and upgrades the previously disabled 3rd party apps one by one, provided of course that compatible new versions are available in the app store.
The first changes including separating the updater from the rest of ownCloud have been made and introduced in ownCloud 9.0. These changes will only impact updates going forward from that release – that is, going from 9.0.1 to 9.0.1 and next major releases like 9.1.
Aside from the upgrade process, the installation and life cycle management of ownCloud, with packages, zip files, containers or a VM, is also under scrutiny. All these methods have their issues and maintaining so many choices comes at the costs of serious time and efforts so we’re looking into ways to get an easier ownCloud installation and upgrade experience to new users. The results of that will show up further in the 9.x series.
There is a lot more work to be done and the upgrade process will require extensive testing. The list of tasks on github for the upgrade process reflects our longer term plan, not something we expect to be done for the coming release. Your help can move this forward, both with coding and testing!
With these changes, we will deliver a much nicer and smoother upgrade process and we hope it will help sysadmins in lowering the load of managing their ownCloud servers.