Dear Community,
Starting this week Wednesday, we’ll be using the weekly Ozone Support Hour to also meet as an “HIS Squad”.
The goal is to set up a representative, re-useable distribution, with a working demo site, of the following apps all combined together:
OpenMRS (3)
OpenELIS
Odoo
Superset
(And maybe adding more later, but that’s enough of a stretch goal for now.)
Our goal is to have a “RefApp” of combined fit-for-purpose solutions that can be used by big, high-complexity, high-needs sites. On the one hand, we do need the OpenMRS EMR to support non-clinical/non-traditional modules in a “Lite” or “Skinny” fashion so we can support the ~80% of sites that are small and don’t need a full ERP etc (e.g. through our Lab-Lite, Dispensing, Billing-Lite, and Stock-Lite O3 apps). However, we also need an option for the bigger institutions. OpenMRS-HIS (aka Distro-HIS) will provide this!
Can’t wait to work on this more with others. If you’re interested, please join us on the Ozone Support / HIS Squad call this wednesday, and weekly after that. Call info at om.rs/cal
Storage Issues on Bamboo: Facing challenges with using Bamboo CI - running into a disk space issue. Wondering if GitHub Actions can be used instead. Madiro running into same problem in GitHub Actions. Everything needs to be in one file, expected by Bamboo CI to deploy.
Building distro images to contain distro.prop files, then we put all that in 1 single image that docker can understand. Way to add all the binaries and configs and everything into a docker image so you just have 1 docker-compose file. Met with Ian earlier and wants to keep all deployments similar.
Custom logic for deploying Ozone/OpenMRSHIS that we had to develop just to deploy on the OpenMRS infrastructure. To be able to copy custom configs into one docker image. Very repetitive process. When you then want to enable SSO in this setup, we need to have even more custom logic; not sure how to do this to be flexible enough at build time - limiting technology and not proper templating. Tried adding deploy step in Bamboo - and now builds all failing.
How Mekom handles this: Runs a special job to free up space from GH Actions agents. Very custom code which may be a real uptake blocker.
Deploying Ozone Analytics (Superset) now blocked.
The question is, do we continue with this “quick and dirty” tech debt approach to templating, or try to do better and hold up our other goals?
Plan:
Step 1: Contact @cintiadr and @burke in #infra channel re. disk space issue
Tickets reviewed: OpenMRS Distro HIS project in Jira: 