Start all modules should sync with only the available .omod files (docker environment)

Development
,
1

The “Start All” button inside legacy does not sync to start only the available the .omod files inside the modules folder in docker environment.

Workflow:

  1. execute inside the backend container
  2. cd openmrs/data/modules
  3. delete/add a .omod file inside modules
  4. go to modules dashboard and click the “Start All” button

Result: Module manually deleted persists in Legacy

FYI restarting the backend container restores the deleted modules hence manually updating modules in docker is somewhat tricky.

This leaves me with only depending on legacy which seams broken in at the moment. The getway times out on adding or upgrading a module

cc @dkayiwa @ibacher

1 Like
2

Because you are using the legacy Start All button, why don’t you even delete the module using the same user interface’s delete icon?

3

Legacy’s delete module icon works, however adding a new module manually and clicking “Start All” doesn’t load this change. in legacy

4

Adding a new module should automatically start it without requiring you to click Start All

5

I am adding it manually by importanting it’s .omod into the modules directory

If “Start All” was syncing existing files well, I would just simply click it and my new module I have added manually gets loaded.

6

Why don’t you just restart OpenMRS after adding the omod? After all, that is what we recommend in production.

7

Restarting the backen container reastores deleted .omod files

8

Stop OpenMRS. Delete the omod. Then start OpenMRS.

9

AFAIK docker will not allow me to execute into a stopped container

10

Can you fully describe the use case that you are dealing with in all this?

11

Inside my docker environment, i have been trying to update the rest webservices module.
The normal workflow is using the add or upgrade button, and then selecting the new version of the rest webservices module but this is not working for docker environtments.

Hardship i go through :frowning:

  1. getway first complains that my upload is too big: Solved with increasing the client_max_body_size to 10M; inside the getway container at /etc/nginx/nginx.conf

  2. The getway then complains that the request has taken too long with 504 gateway time-out nginx. Refreshing the browser or going to the legacy home throws a 500 internal server error

  3. I then just have to restart the backend container which restores the previous .omod file of the rest webservices module i wanted to override. This results in me having two .omod files for the rest web services module. I know legacy modules’ list shows the actual name of the .omod file loaded but it gets confusing when both new and old .omod files have the same name ie mostly when openmrs is running a snapshot version of the module by default.

How i walk around this :frowning_face:

  1. When selecting the .omod file to upload, i change its name to give it unique characters. Then i will just check in the modules UI to check if my new .omod file is started. (remember I have two .omod file of the same module)

  2. In docker, I import my new .omod file, whose name is different from the current module i want to override and restart the backend container. At the same second, i delete the old .omod as the container is restarting. This most times breaks modules so i restart all of them from the modules UI.

  3. I just turn to the OpenMRS sdk and with continue the normal, stop, update modules, start and wait …

This is why i think life can be much simpler if i just add/delete from the modules folder and then just click start all ‘Start All’ which will sync my change to the modules folder

FWIW, we might also need to increate ignix’s request timeout

12

So the way I usually develop modules with Docker and OpenMRS is to provide the OMOD as a Docker volume. Usually I just overwrite the pre-existing OMOD I care about. This is done by having something like this in the OpenMRS service configuration in docker-compose:

volumes:
  - "./webservices.rest-2.42.0-SNAPSHOT.omod:/openmrs/distribution/openmrs_modules/webservices.rest-2.41.0.omod"

That gives you only one version of the module and it’s consistent across restarts of the container.

3 Likes
13

This will save me some good time.

While trying to dodge this yesterday i added some two lines of code to legacy and Start All did what i wanted.

thanks @dkayiwa @ibacher