We are currently running openBIS version 20.10.7.2 in a production environment and are planning to upgrade to 20.10.12+.
As our installation contains a significant amount of data and is actively used by multiple users, we would like to ensure a smooth and safe upgrade process.
Could anyone please guide us on the recommended upgrade procedure or point us to the appropriate documentation for migrating from 20.10.7.2 to 20.10.12+? We are particularly interested in:
Recommended upgrade steps for a standalone installation.
Any database or datastore migration considerations.
Required backups and rollback procedures.
Potential compatibility issues or breaking changes between these versions.
Whether an intermediate upgrade path is recommended or if a direct upgrade is supported.
Any advice, best practices, or experiences from similar upgrades would be greatly appreciated.
Hi Shiva,
We’re also investigating how to do a migration, but in our case, we will migrate from openbis-debian docker container to openbis-app container setup.
The key differences are:
postgres database is running in a separate container
openbis internal folder structure is different to the former
I found a short guide on openbis team’s dockerhub on how to do such a migration. Now we’re in the process to go through the backup and restoration steps in a testing environment to see if it works before we do the actual migration. See the guide: openbis/debian-openbis - Docker Image
Since you use openbis 20.10.7.2, the internal structure is most likely similar to that of openbis-debian container.
Maybe this can help you in the right direction, and if it is of interest, I can keep you posted as well.
Yes of course,
I’ll let you know how it goes during the process.
Prior to the Restore step when the debian-openbis.sql dump is restored, I highly advice you to make sure you have a completely fresh openbis docker instance, where you first remove the postgres database before restoration, see @artur.pedziwilk answer: How to migrate a standard openBIS installation to a docker installation
There might be more leads to help you in this matter as well.
Dear @Shiva,
we do not specifically provide any recommended upgrade procedure since we do not provide any dedicated package of openBIS for any operating system.
openBIS is a Java application designed originally as Java container with flexibility to install and run by Java Virtual Machine.
That flexibility allows any upgrade approach as decided by openBIS operators.
I can provide several key points from perspective of our production systems (standalone and docker containers).
We generally now focus on and recommend to deploy openBIS docker containers instead standalone. If I mix referring to documentation between standalone and container please be aware to not blindly follow the commands, in most cases the commands are prepared in the way where something provided by “docker exec openbis-app command” would mean for standalone setup just “command”.
Datastore and application logs are out of this context, just do not run several openBIS installations pointing to the same data store location on disk or NAS and the same directory of logs.
The most challenging part is openBIS configuration, because in most cases unsuccessful upgrades are due to misconfiguration of the system, not the openBIS release itself. And for this reason we maintain openBIS deployments in following practices.
We deploy openBIS in release specific directory with symlink
openbis → /home/openbis/openbis-20.10.12.5
so at any moment referring to /home/openbis is always to active instance and desired release. With correct database backup the upgrade and the rollback are very easy and straightforward as a standard procedure.
We have configuration management system and we apply correct configuration continuously to each releases, what would be not easy on “in place” upgrades.
I know developers are doing “in place” upgrades using “servers/openBIS-server/jetty/bin/upgrade.sh” script but since there is not any “rollback.sh” script, I would never use it in any production system. In openBIS 7.x we have dropped this script completely as our development workflows are migrating do containerized environments too.
Additionally to database dumps backups, we regularly backup file based user passwd and personal access tokens. I could actually say it is good practice to backup the whole configuration (not so easy for openBIS standalone) Backup — Python documentation
There is generally no compatibility issues and all is mentioned in CHANGELOG, but database tables are upgraded so rollback needs database restore, it cannot be just release rollback on upgraded databases.
openBIS 20.10.x does not have breaking configuration changes, however configuration issues are most cases of upgrade problems. Docker containers are easier to manage from configuration perspective.
All additional necessary steps of upgrading are mentioned in CHANGELOG so it is good to read all of them added between specific version.
We also try to keep the application deployment clean and we empty openBIS trash, we make sure there is no ongoing maintenance tasks or archive/unarchive processes, I even reboot the whole system before upgrade to force user’s session invalidation and make sure the system is healthy shortly after reboot.
Please consider containerized openBIS deployment from our openbis-app container as we are focusing to make configuration of openBIS easier in such a setup. Additionally an isolation is high security advantage as well as flexibility of container (high availability setups) it is easier to redeploy container on another sever or even another cloud provider.