Recently, I have faced an issue with LogManager module installation. I just downloaded the LogManager updated version from the AddOns and installed through the sysAdmin OWA. But immediately after the installation, I got some errors due to spring and bean. I couldn’t use the Reference Application after that installation (totally crashed due to some errors). There are no ways to access the services at that moment so,
I tried to restart the server, but I faced the same situation again and I was unable to enter the Reference application to remove the LogManager module.
Finally, I have decided to delete the LogManager omod file from the server manually to roll back to the previous working state.
My concern is, Why we can’t implement this Auto Rollback feature through SysAdmin OWA or AddOn Manager OWA? It would be awesome, If those OWAs provide these following features to the users,
It should check for the required OpenMRS versions and required modules before the installation.
If there are any errors occurred, It should automatically remove the module from the directory or OpenMRS reference application and should pop up the user about the installation failed (Currently, Both OWAs only show the error stack from the Module installation as the error message and still module copied to the server directory - So restarting the server also will cause the same failure again) - Rollback feature.
It will be helpful to avoid the unexpected failures due to new module installations or module updates. Because some users might not have the knowledge to remove the module files manually from the server. Are there any suggestions about this concern?
I have faced those issues during the development time. So then I came to this idea.
If we plan to implement the rollback feature, then We can simply add this to SysAdmin and Add Manager OWAs.
@suthagar23 it would be very nice to address this, though it’s a bit tricky.
I assume this is already being done, but if it’s not then that’s an important bug that should be fixed.
One problem is that while OpenMRS won’t load a module if its stated dependencies are met (required OpenMRS version or required modules), modules generally only know the minimum required OpenMRS Platform version (e.g. logmanager says 1.7.0) but they don’t know about future platform changes that may come along and break them. (I would assume this broke in Platform 2.0.0 but that’s a complete guess.)
The larger issue is that we don’t have an easy way in the OpenMRS code to recover since if the Spring module application context fails to load, then OpenMRS is not running.
We shouldn’t automatically delete an OMOD file if it fails to load. (Maybe the admin doesn’t know how to fetch it again.)
Maybe something we should do in openmrs-core is that when a module is first added, and spring fails to restart, then we flag it with a different state. (Maybe this requires setting the ${moduleId}.started global property to some new special values like “starting first time” and “failed first time”.) We’d need some kind out filter/handler outside of spring to recover from this situation.
Anyway I do think it’s worth spec-ing this out, and solving it in any way that’s feasible.
