So asking for everyone mentioned there, @raff, @darius, @wyclif, @maurya and @dkayiwa, can you please update that page with the purpose of each environment, if there’s someone responsible for it?
Can I destroy dev01 and dev02 machines?
Can I move uat-refapp to docker, just like I did qa-refapp?
What needs to be done to dockerise dev00/msbuilder?
Is there any plans to create a docker image for the platform from the SDK (just like the one for refapp)?
We used to run automated tests on devtest01, but we now run them on a server on travis-ci.
Devtest02 used to be what qa-refapp is now.
I think both machines can be destroyed.
It would be great! Can you make it so that it deploys the uat branch instead of master?
It’s running a platform. Before each RA release we need load a sql with the CIEL concept dictionary on that instance. Also we need to take backups of the db. Let me try to create a docker config, which could be used for that machine.
Well, yes, can. The problem is that today the refapp distro build is all based on master, and running another branch would have undesired effects (like the deploy of snapshot, deploy to the manual server, and so on).
Instead of having a branch build, I’d rather have another build for UAT.
Is there any reason why we’d have a different branch for UAT? Note that the UAT server would use the ‘uat’ docker tag, so it wouldn’t be affected by other deployments.
I see. Because it’s platform (and because it has state), I don’t want to mix with the others, then. No need to hurry with the docker image, I’m not going to be deploying it any time soon
Awesome! I will play with it later.
We just have uat-platform and int-platform. Does it make sense to have qa-platform and uat-plataform only? Do we want to deploy master or maybe different platform versions?
Done. I’ve not been a fan of creating more places for content anyway. The old help desk page now directs people to the wiki page.
I adapted some text from the old Test Servers page and added into a “Developer Test Environment” section.
@cintiadr – it would be nice to have a “pool” of up to 6 devtest instances that we host for developers doing sprints or spikes to demonstrate their work & get feedback. ITSM-4003 (a demo environment for the Andela sprints on Cohort Builder Enhancements is an example). Something like:
Developer requests a devtest environment for a sprint or spike including their contact info, purpose, the build needed (Platform or RefApp & version), TTL in days or weeks, and their public certificate.
We use the information provided to create a document for terrraform to automagically deploy their devtest environment during the specified date range. The developer is responsible for maintaining the environment during that time. Ideally, we’d give them a (semi-)automated way to refresh (re-deploy) or release (delete early) the devtest environment.
We still have a couple devtest environments lingering without a clear TTL.
Thanks
Based on the amount of resources we were using, I decided to start tackling the ‘long-lived’ environments first, and leave the devtest ones for later.
The easiest way (by far) for me would be using docker.
Let’s assume I have one docker host for devtest machines. Someone willing to have an openmrs instance would need to follow https://github.com/openmrs/openmrs-contrib-ansible-docker-compose . From there, any docker tag pushed is automatically deployed (no CI involved).
That simplifies the problem immensely to me, because there’s no users, no tomcat version, no mysql, and it’s a single machine to take care with ansible/firewall/security patches or anything. Even the time to provision a new instance is much smaller.
Would it be too much to ask for docker in this case?
That’s fine; however, it would be nice not to expect developers to publish their own docker image.
Assuming a developer has a good case for a devtest image*:
In most cases, they’d want a specific version of Platform or RefApp, in which case we’d use community-managed Docker image – i.e., we’d add an entry to terraform config that included owner, purpose, date range, and Docker images to use.
In advanced cases, they could publish a Docker image and we could point terraform to that instead.
I’m guessing it’ll take more than just a single image. More like a docker-compose containing at least application image & database image.
*I’m picturing Developer Test Environments primarily for community sprints & demos. Devs who just want a hosted instance of OpenMRS to play with or demo for personal or non-community needs (this would include most GSoC projects) can be encouraged to host themselves via DigitalOcean/AWS/etc.
Devtest03 is serving as our demo of OpenMRS Ebola. I’d like to keep this
demo alive for the foreseeable future, though I’m fine moving it to a non
devtest server. That hasn’t seemed like a priority so far.
(If we’re somehow resource constrained then I can talk with Jonathan and
Hamish about us paying for a digitalocean server or something. But we have
just submitted a paper that refers to the demo server, via short link, so
we definitely want to keep it alive.)
