My objective was to tweak hibernate c3p0 sizes which comes under the hibernate properties file at runtime.
From the OpenMRS startup_init script, it creates a server properties file at runtime (lines 121-137) and overwrites runtime properties file if that file already exists, which brings me to the following questions
Does OpenMRS allow tweaking runtime properties other than the configurable environment variables in startup_init script (eg: hibernate.c3p0.max_size)?
Is there any reason why certain properties are non-configurable?
Wouldn’t the server properties and runtime properties files get overwritten at all times, considering the lines 121-142 in startup_init script, and also bringing in 2 exact copies of the same file?
Yes, we do allow tweaking runtime properties. Unfortunately, if you run in docker then you are restricted at the moment to what is listed in startup_init.
The reason they are not all listed in startup_init is that there’s so many options and we didn’t put them all in there. You are free to add whatever you need to startup_init and send a PR to openmrs-core and a branch where you need it.
Yes, they will get overwritten. We could tweak the script not to overwrite, but do a merge to be more flexible. In a docker context it is preferred when configuration is driven by environment properties and not a file.
We will be in a better place once we make a change to openmrs-core to read properties directly from environment variables in addition to the properties file. If you have some spare dev cycles, I encourage you to contribute that. Once the feature is in place then there is no need to list all properties in startup_init… It’s a matter of changing one method openmrs-core/OpenmrsUtil.java at 3fd9c9bf968f182fcfc4f56843717a3bd29b141f · openmrs/openmrs-core · GitHub giving the priority to environment variables over the config file. It would work more like what is supported by Spring Boot see Core Features
Yes. Ideally, OpenMRS community images should strive to be as flexible as possible. For example:
Introduce or override global properties via direct environment variable with predefined prefix (e.g., OPENMRS_GP_visitsEnabled = true)
Introduce or override default global variables by introducing a file containing custom settings (e.g., mount the file to a predefined location in the image)
Run custom SQL on startup (e.g., by mounting a file or folder to a predefine location)
It would be great if you could give an insight as to why this approach of overwriting in the startup_init script was taken. Would like to know what was the thought process behind that.
Also, how do we change the hibernate values in OpenMRS?
Environment variables in containers take precedence over any other settings as it’s the most convenient way of configuration in clustered environments, which doesn’t require any file handling, thus the overwrite. The expectation is that if you change an environment variable, it will be reflected with the service redeployment.
As I wrote we need to extend startup_init to include any additional hibernate settings and instead of overwriting we may merge startup settings with the runtime properties file. These are quick changes, which I can address tomorrow and have them available for testing in nightly builds of openmrs-core.
The original goal of the images with that startup script was to create a generic image that could be used for any version of OpenMRS from 1.9-2.5+. As part of that, we wanted to adhere to the idea that environment variables should be the main mechanism for configuring the properties of the application, i.e., if you tweak the JDBC connection string via an environment variable, the application should use that.
As @raff pointed out above, OpenMRS doesn’t currently take environment variables into account. It uses the openmrs-runtime.properties file, so to try and backport the ability to change things in the Docker image on-the-fly, we needed to overwrite the openmrs-runtime.properties file.
Note, however, that there’s nothing in the image itself (or the start-up script) that’s blocking you from using it for other purposes… You could, for example, overwrite startup_init.sh with your own version that did whatever configuration you wanted or change the environment variables that determine the path the runtime.properties file is saved to use a different location and then mount a custom openmrs-runtime.properties file in the /openmrs/data folder.