@pkornowski As far as I know we have fixed SYNCT-84, right? Is there anything that should be done on our side to allow community using Sync 2.0 on our demo environment?
What about credentials? Have we published them?
The current MVP is deployed on the Demo servers. The scheduler works all the time and the Pull & Push intervals are set at 30 sec. To test if that works I attach current connection between our server instances: https://wiki.openmrs.org/display/projects/Sync+2.0+Demo+Environment
There is possible to synchronize Patient object between instances.
The credentials are not published yet. There is a problem with creating a non-admin user which should be used for testing Sync 2.0. We work on this with @raff and I think tomorrow credentials will be published.
we are working on supporting the OpenMRS 1.x via the Sync 2.0 module. Is this possible to run other 2 (or more) instances of the OpenMRS Platform (legacy OpenMRS, for instance 1.9.10 version) on the same machine (which is currently used by Sync 2.0 demo environment) at the same time? This could help us with testing the Sync 2.0 module.
Kindly regards, Arek
I doubt we have enough memory for it in that machine.
So, please let me know:
- how many instances do you actually need?
- for how long?
- is there docker images for those versions? We just deploy docker to keep my sanity.
We want to have existing 4 instances and add 2 other instances on legacy OpenMRS. I understand your doubts related to memory size. I wonder if we can manage via the CI which instances should be running (for instance 2 - OpenMRS 2.x and 2 - OpenMRS 1.x).
We need these instances only for the test. The longer they will be available, the better. These instances will be useful for projects which are interested of using the Sync 2.0 on OpenMRS 1.x (they could test the Sync 2.0 module before deploying on production server).
We can’t use existing docker image to deploy the OpenMRS Platform 1.9.10 because it is based on the openmrs/openmrs-reference-application-distro (correct me if I am wrong). I couldn’t find any docker image on the Docker Hub which fulfills the requirements. Do you know some docker image which uses the legacy OpenMRS?
I will check later if we have resources on that machine or which VM could be suitable.
That said, how much time you’d like to have? 3 months? 6 months? A year?
Your build is creating a docker image for openmrs refapp - I assume using OpenMRS SDK ‘build-distro’ command.
The dockercompose file is available as well on that page.
While I’m not against deploying it at all, I’d prefer to have a date to shut them off. I also need someone to create the docker image + docker compose. I have no idea if the SDK supports that version of core.
I can definitely try to help creating the image, but realistically talking I have a huge backlog to go through for the next few weeks. If you have the image and docker compose, my work is very straightforward.
Some good and bad news @alalo:
We can add 2 more openmrs instances to the same machine without much drama.
Apparently it’s not supported. I believe only 1.10.+ work out of the box.
I have the feeling that if you want to deploy 1.9.x, you might have to create the docker image from scratch, or modify the SDK to support it.
I’m not sure if we support 1.9.x or if it’s EOL’ed already.
We no longer support 1.9.x
Thank you very much for your investigation.
Based on the docker-compose file of OpenMRS SDK I prepared the Dockerfile and docker-compose files. These files are available here:
Please take a look and let me know if this is what you need. Thanks in advance.
I added a script which could be used to update the version of modules (more info you can find in the repository README). That script is named manageModules.sh and is placed on the same repository.
Sorry I missed this question. I believe a year should be enough.
@cintiadr any update on that? Can I do something else to help you with creating that demo environment?
With some luck, I will do it over the weekend.
If that’s not possible, I will try to at least write up how you could help me.
Can you do me a favour?
Can you raise an ITSM ticket with this? So I don’t forget
Best Regards, Tomasz
(note, some of those files are symlinked) If you want to do any changes, please create a pull request for me. It’s probably mostly fine.
Now you are responsible for creating the docker image.
I’d recommend you do the following:
- copy openmrs-distro.properties file to, let’s say, openmrs-legacy-distro.properties
- change distro.referenceapplication from 2.6.0 to 2.4 (oldest version supported by the SDK, core version 1.11.6) , and run
mvn openmrs-sdk:build-distro -Ddistro=openmrs-legacy-distro.properties. You should be able to run
docker-compose upand verify it has the right configuration.
- change build Deploy sync legacy to use the new file
We might have the adjust the dbdump (maybe).
Thank you for your help. I’ll try to take care of it when I’ll have free time
Hi @cintiadr ,
the Atomfeed module uses the third party library which has a different version for OpenMRS 2.x and OpenMRS 1.x. That module by default use version compatible with OpenMRS 2.x, to use that module with OpenMRS 1.x we prepared the specific Maven profile which uses the different version of a third party library.
Currently on the jfog (I believe that is used by the OpenMRS SDK, correct me if I am wrong) we have deployed the version of the module compatible with OpenMRS 2.x. Do you think it is possible to deploy there also the version of the module which is compatible with the OpenMRS 1.x (the module build with “openmrs-1.9” Maven profile)? Because for now I can’t properly configure the “openmrs-legacy-distro.properties” file (suggested by you) to create the docker image.
Link to atomfeed module on jfrog: https://openmrs.jfrog.io/openmrs/public/org/openmrs/module/atomfeed-omod/
Thanks in advance, Arek
We do not recommend shipping different builds of the same module for different platform versions. Did you take a look at this? https://wiki.openmrs.org/display/docs/Supporting+different+OpenMRS+versions