@michaelbontyes raised a really interesting issue with me today:
In the RefApp currently we have 2 docker volumes: the OpenMRS Database, and OpenMRS Data.
Your OpenMRS Data Volume (looks like openmrs-data volume) contains complex_obs, like patient photos/attachments for example (as you can see in the screenshot below).
Sometimes when you have changes in your Docker cache, or updates / new versions in your binaries, or for backup reasons, you will want to start fresh with your volumes.
But: you have to be really careful about resetting this because you have patient data, like patient attachments, in the same volume where you have OpenMRS binaries and configurations. So you could update your binaries and lose those complex obs.
I totally understand the difference between patient data that cannot be automatically recreated, and the other categories. I had never thought of this. And for these cases, i would vote yes to using the same approach as Ozone.
We can definitely put complex-obs in a separate volume, but that’s not enough in most cases. Unfortunately before openmrs-core 2.8 module devs were only advised to put files in the application data directory and by design we didn’t maintain any separation between config, metadata, binaries, patient data regardless if it’s in a docker volume or an OS directory.
In openmrs-core 2.8 we introduced StorageService, which should be the main way to store files that do not fit in DB. It is configurable and it can store data using different means. Out of the box we will provide a local file system and S3 support for clustered environments. Modules can provide other integrations.
We back-ported StorageService with local file system support as far as openmrs-core 2.5.x for ease of use in modules supporting older versions of OpenMRS.
Yes. My concern about Ozone’s approach is that it’s extremely sensitive to where modules actually store data. As @raff points out, the StorageService is probably a better long-term solution for this kind of thing, but it’s my view that everything in the OpenMRS data directory should be backed-up anyways, even if it’s duplicative of what’s otherwise in the distribution.
By design, when using the OpenMRS Dockerfile, the places that OpenMRS artifacts are stored are overridden by whats in the distribution configuration, modules, etc.
The error here is wanting to support resetting the volumes. I think this is an issue introduced by the way Ozone is structured and not something the RefApp should worry about. In essence, the design around this is precisely that restarting the Docker container should be enough to reset the binary files and you should have no good reason to reset volumes other than wanting to destructively reset your implementation.
But: you have to be really careful about resetting this because you have patient data, like patient attachments, in the same volume where you have OpenMRS binaries and configurations. So you could update your binaries and lose those complex obs.
