Can I make a small feature request for the Bahmni installer?
I really like how in the latest version (0.81), the bahmni-emr role in bahmni-playbooks has been fixed such that additional omods can be installed from URLs that are implementation-defined, and not limited to the https://bahmni-repo.twhosted.com/omod/ repository. Thanks for doing this!!
However, it would be great if we could have an option for installing additional omods from anything within /etc/bahmni-installer/deployment-artifacts/omods/*.omod. This would allow us to use whatever means are best for our implementations to identify and retrieve the additional omods without having to support this variety of options within the bahmni-emr role. As a concrete example, I’d like to be able to install offline, without requiring internet. There is probably a way I could rig this by putting the omods under /var/www/ and then using localhost, but it would seem to make more sense by just using deployment-artificacts, since that is what we already do for the bahmni_config and starter db.
One nice-to-have addition - we would ideally want this to be smart enough to override an existing version of a module, rather than just assume it is a new module -eg. if we wanted to install addresshierearchy-1.10.omod and addresshierarchy-1.8.omod comes with Bahmni, we would want to be able to specify this later version of addresshierarchy and have the system smart enough to not end up with both omods in the modules folder.
Thanks for considering this feature. Please let me know if it is able to make it into the next release and/or if you’d consider pull requests for this.
Hi @mseaton
The suggestions you made are good. The first one is kind of easy but the second one might need some analysis. I might not be able to comment when this will be available but these will definitely be taken into consideration. Will update you after speaking with the team internally. Thanks Mike
@bharatak: At minimum we could create cards for the two requirements in Mingle, and put some thoughts / estimates there, and then prioritize accordingly after discussions. What do you think? If yes, then can you reply to this thread with the mingle card numbers. Thank you!
@mseaton: have you done this already? if not, we will pick it up. btw, ansible get_url should work with “file:///some-directory/xyz.omod”, but this would mean that you specify each and every file. Will this work for you?
I am ok with either, specifying just the directory will also play well with the card #1638.
Good to know that the existing solution will work with the file prefix - I hadn’t thought of that!
I did not do this already. If it’s helpful I threw together a quick shell script at one point to attempt to handle the two steps above (copying omods over and overwriting previous versions if they exist). Not sure if this is at all useful:
> #!/bin/bash
> SOURCE_DIR="/etc/bahmni-installer/deployment-artifacts/omods"
> TARGET_DIR="/opt/openmrs/modules"
> if [ -d "$SOURCE_DIR" ]; then
> for omodFile in $(ls $SOURCE_DIR/*.omod)
> do
> echo "Installing module: $omodFile"
> moduleNameAndVersion=$(basename $omodFile)
> moduleId="${moduleNameAndVersion%%-*}"
> rm $TARGET_DIR/$moduleId-*.omod
> cp $omodFile $TARGET_DIR
> chown bahmni:bahmni $TARGET_DIR/$moduleNameAndVersion
> done
> fi
Thanks for taking this on and sorry we were not able to get to it yet.
Hi @mseaton
As of now we do not have any standard way to define the omods version. Hence we will not be able to use the script to find the version for a particular omod by a single regex expression.
We are building capability to copy external omods from a folder or download omods from url.
@vikash, sorry I’m not entirely sure I follow. I don’t think there is a particular need to find the version. There is a need to ensure that two different omod files for the same module don’t end up in the modules folder. From my original post above:
@mseaton
problem is that omod names are not consistent. for example, in folder, we may find omods named as:
idgen-webservices-1.1.omod
idgen-webservices-1.1-SNAPSHOT.omod
openmrs-atomfeed-2.5.1.omod
addresshierarchy-2.8.omod
The best we can do is with a regex like “.+?(?=-\d)” to use in a script to delete and override files starting with the name like “idgen-webservices*.omod”
note, in the above example, idgen-webservices-1.1-SNAPSHOT will be one in modules directory, which is not what we want.
@angshuonline. I’m not sure what you mean by “not what we want”. If, in my configuration I say that I want “idgen-webservices-1.1-SNAPSHOT.omod”, then I do think that this should override “idgen-webservices-1.1.omod”, even though it possibly reflects an earlier version of the module. It’s on me as the implementer to understand the consequences and implications of this decision. We certainly don’t want both of these in the modules folder at the same time.
Based on module naming conventions, I would have though that we can identify consistently the module id and version of any module simply based on the filename of the omod. Are there known examples where there might be ambiguity, or where you think we would inadvertently replace the wrong omod?
@mseaton: we are not mentioning anything in configuration for the filenames.
specifically for this feature, we are going to inspect the files in a directory, determine the “right” omod and copy to /opt/openmrs/modules.
I am not sure if we should override the “idgen-webservices-1.1.omod”. because module naming are not consistent.Typically, a released jar/omod can follow one of the naming convention below (the number & suffix is of relevance here)
idgen-webservices-1.1.omod
idgen-webservices-1.1-RELEASE.omod
If the source directory have the files as below, invoking the script will result in only the SNAPSHOT version retained in target directory.
idgen-webservices-1.1.omod
idgen-webservices-1.1-RELEASE.omod
idgen-webservices-1.1-SNAPSHOT.omod
thats because the script is just sorting by name of omod files in the directory and removing and copying files. the “snapshot” file appears later in listing hence the problem.
I see your point. My contention though is that such a complex scenario will not really apply. All we need to ensure is that we can identify that all of the above refer to the “idgen-webservices” module. We would simply iterate across the custom omods defined, and for each:
Parse out the module id from the filename (idgen-webservices)
Remove all omods from /opt/openmrs/modules that are in the format of {{module_id}}-number-*.omod
Copy the omod file into /opt/openmrs/modules
No version comparison is needed because whatever is specified in in the bahmni_config should always win.
@mseaton: thats what we are doing.
only that in step 2) we are removing all omods with the pattern of {{module_id}}_*.omod
note, this will be available in upcoming release v0.83
@angshuonline great - looking forward to it. The reason why I put {{module_id}}-number-.omod and not {{module_id}}-.omod is in the case where you have something like “idgen-webservices-1.1.omod” already installed, and you want to install a custom (newer) version of “idgen-6.7.omod”. If you are simply matching on the {{module_id}}-*.omod, you’ll remove the idgen-webservices module inadvertently…
