There are a number of modules installed manually on qa-refapp, which makes it a customized version of RA 2.6. I thought qa-refapp is to be used exclusively for RA SNAPSHOT testing. Is that right? Is it okay, if I remove the extra modules?
@cintiadr, I notice there’s a SNAPSHOT version of an RA docker image pushed to the docker hub already. How far are we from using docker for qa-refapp same as for demo and resetting it with every build?
You are correct.
What you are seeing is a result of our not having a publicly available server where community members can test compatibility of their modules with an upcoming reference application release.
In summary, i agree with removing them. But before we provide an alternative server for such a need, then i would rather they stay.
@dkayiwa, we can surely set up a server for this purpose.
What name would you give this server? And what would be the one-line description of its purpose?
Excellent! 
Name: mc-refapp.openmrs.org (Where “mc” stands for module compatibility) Description: Server for testing compatibility of modules with those in the upcoming reference application release.
@dkayiwa, I’m afraid that “mc” won’t be so memorable to people, so how about we call it modules-refapp instead of mc-refapp.
Go ahead and create a ticket for this at help.openmrs.org. (Sorry, I should have said that in the first place.)
It’s actually pretty simple! I just didn’t stop to do it yet. I can do it this weekend.
So, we’d have a modules-refapp.openmrs.org, which I assume should be reset every few hours? (12h? 24h?) I can also make qa-refapp.openmrs.org inside docker too at the same time, and deployed on every green build (as it’s already like that).
@cintiadr i would not automatically reset modules-refapp.openmrs.org for the sake of those bugs that are exposed by existing data.
@cintiadr, we would like to reset and deploy qa-refapp every green build.
It would be great to be able to reset and deploy modules-refapp on demand only through a CI plan triggered manually in case something breaks.
This is almost done. https://issues.openmrs.org/browse/ITSM-3994
Dockerised qa-refapp: https://qa-refapp.openmrs.org/openmrs/login.htm Dockerised modules-refapp: https://modules-refapp.openmrs.org/openmrs/login.htm Deploy and reset modules-refapp: https://ci.openmrs.org/browse/REFAPP-RM (I will improve the build as well)
The docker-compose files for both are in:
Anything you wanna to change, please just create a PR 
What is missing:
This is awesome @cintiadr
Can we set module.allow_web_admin=true in the runtime properties file for? https://modules-refapp.openmrs.org/openmrs/login.htm
I don’t think we should do this. Letting people upload arbitrary modules is too much of a security risk (because basically they can run arbitrary code on our infrastructure.)
Unless we change things so that people can’t have admin access with a well-known admin password.
Changing module.allow_web_admin=true or the admin password is the same for me. I can even create a couple of other users, and save the database, it shouldn’t be that complicated.
While it is arbitrary code, it’s running inside the JVM and inside docker. While I’m not ignoring that there’s always the possibility of getting out of the container, we are not giving extra permissions to the docker containers we are running.
So, while there’s always risk, it’s not so easy to compromise it compared a ‘regular’ installation outside docker.
In that case, how will developers upload modules to test their compatibility with the reference application?
Turns out I will need to change my webhook scripts in order to allow dockerhub to deploy the same image (openmrs-refapp-distro) to multiple openmrs instances running on the same box.
(For now it’s SSH, and it’s working ~fine, but it’s not the best solution. I will work on that.)
@cintiadr was the SSH line a response to my question of how developers will upload modules to test their compatibility with the reference application? Or were you talking about something else?
Someone would need to create user accounts for them (via the OpenMRS UI).
Or do you think it’s important that anonymous people be able to upload modules?
I thought we would have the same commonly known account like admin/Admin123 That way, we do not burden ourselves with unnecessarily extra work in addition to blocking someone up to whenever the permission request is granted.
If @cintiadr (representing the infra team) is okay with us allowing module uploads by anonymous people, I’ll go with that.
My own preference is that we do require people to ask us “can I upload a module to the modules-refapp server” and we manually create an account for them the first time. (How often do new people want to do this? There aren’t that many modules out there, or that many module authors.)
Currently, for modules-refapp.openmrs.org, even an admin user account cannot upload modules via the web interface because module.allow_web_admin=false Was this intentional?
It’s intentional that our standard server deployed by the infra team does not allow web management of modules.
I agree with you that for the “module testing server” we need to be more permissive. We just need to decide how permissive.
(I suggest, @dkayiwa, that since you have the most emotional ownership over the modules-refapp server, that you just decide how this should work. You’ve heard what Cintia and I had to say. Now you can make the call.)