auto-update feature for OpenMRS distributions

Implementing
#1

Hello everyone,

We are in the process of designing an auto-update feature in KenyaEMR, and should at the very least provide the following:

• Check a remote site (updates server) via HTTP for a newer version.
• If a newer version is available, download it as a ZIP.
• Handle OpenMRS upgrade procedure as documented at https://wiki.openmrs.org/display/docs/Upgrading+OpenMRS
• Resist tampering.
• Accommodate some simple logging.
• JSON/XML file configuration.

The idea is to allow users with admin privileges to check for updates/upgrades from an updates server, and provide links to download a preferred package. The downloadable package should be self contained with the war file, modules, metadata, and scripts (possibly shell) that will handle the whole upgrade process.

Are there similar efforts within the community for such, or anywhere I get get information on how to go about it? @jdick @dkayiwa @mseaton @mksd @ssmusoke @burke

1 Like
#2

@aojwang While that approach seems excellent it is bound to cause lots of problems since the upgrade of a module may require other modules to be upgrades which can lead to compatibility problems

What we do in UgandaEMR is to publish updated WAR files for our distribution with updates that are downloaded and applied manually by the sites - there are lots of people trained to do this.

If you want to go the automated route, I would suggest that you create script which checks a known url for a new version, downloads it and replaces the existing WAR file

4 Likes
#3

Thanks Stephen for the prompt feedback. I had the following workflow in my draft idea:

  1. Automated way of notifying a user about a new version. We need an update server to provide this information.
  2. A user manually downloads the release packages from the server. The package here means a complete set of OpenMRS upgrade package with war file, modules (with all module dependencies addressed), metadata i.e. concept dictionary, and deployment scripts bundled together
  3. A user manually initiates the upgrade process but executing a script, probably shell, that takes them through the other upgrade stages

The workflow works well if a distribution provides a complete setup of the OpenMRS components. My assumption is that most module dependencies will be dealt with when developing, and a bundle of the new set of modules prepared for distribution. @ssmusoke more thoughts?

Asante

1 Like
#4

Are you planning to reuse the check for module updates feature which we already have under the manage modules page?

#5

Thanks, @dkayiwa. The check for module updates feature requires one to do that for every individual module that needs to be upgraded. I don’t think it is appropriate if one already has a complete set of what needs to change i.e. war file, modules, etc. My wish is to have a distro with latest war file and modules as a single package for ease of upgrade.

#6

What i mean is that, instead of an update for a module, you replace this with an update for your entire zip package. Same process/code but different contents.

#7

And by the way, are you planning to attend today’s TAC at 5pm Nairobi time? This is the topic: 2020-10-22: TAC Deep Dive - (1) Easier Deployment Packaging and (2) FHIR Extensions

#8

This makes sense @dkayiwa.

#9

This definitely requires more discussion and deep-dive time, but some of the approaches we have started taking (or are currently using) in our distributions (at PIH) include:

  • Publishing distributions as versioned artifacts to Maven via a release process. One can then query a given Maven repository for new versions (releases and/or snapshots), and use this information to drive an update workflow.

  • Publishing distributions as versioned Debian packages, and using standard Ubuntu package management (apt-get update, etc) to check for new versions, download new versions, install new versions, etc.

One could easily imagine similar approaches with Docker images and other types of artifacts.

Mike

1 Like