Do we really want this pointed to a NBO server? @jpayne perhaps we need to think about a more robust cloud platform that can serve different regions quickly. I have submitted a request to AWS to see whether they can provide a charitable platform for us.
Andy
I’m not entirely sure what’s being proposed, so let me break it down.
At the beginning of OCL client project, I had two options to deploy it: (a) as a static web page server / nginx docker container or (b) static resources served by S3/Cloudfront.
Due to the lack of senior frontend/react developers who could debug the eventual caching problems caused by having a CDN in front of your application, and as the download penalty is pretty much on the first request only, I thought the reasonable tradeoff was to ship as a docker container instead and avoid CDNs altogether. I don’t have the bandwidth or knowledge to handle cache invalidation problems that eventually arise from multiple deployments. Due to the pacific ocean, my loading times tend to be worse than most of the world, and it looks fine on cold cache for me.
That said, even if we serve the static files for the OCL client from a CDN, the actual user experience is affected by the latency of the backend.
If you want to add the the backend to the CDN, it’s a whole new world of cache complications. In order to benefit from caches for GET/HEAD, you need to carefully modify the application and the CDN config to know exactly what to answer and what to cache. It’s something I’ve managed to carefully avoid in my career, and some people make a living out of that.
We do have Cloudfront configured, we could see how expensive it would be to add OCL based on load if you have bandwidth to actually tune its cache policies.
I’m not entirely sure why you are proposing the move to AWS. If you are, you know that the docker-compose config is public to be copied. An EC2 instance is not going to provide any more availability guarantees than what we have right now, you wouldn’t gain any improvements in network latency across the world, you’d lose a lot of benefits you have now (network securities, OS patching, backups, https) that you’d have to configure or implement it yourself (if you don’t have someone that already did that for you). In all fairness, most of downtime we have right now is caused by our security patches being applied, which you are not going to be moving away from. Maybe you could get away with ECS/Fargate or Beanstalk, still, you’d have to do a few tradeoffs. It’s always interesting to get developers to learn how to deploy their code as infrastructure, I’ve never got particularly good results.
If you require high availability, you’d probably have to change the architecture to allow multiple replicas of each component. Possible try to use managed services instead.
Now, I wouldn’t know what you mean by ‘serve different regions quickly’ if it’s not a CDN, which doesn’t require the backend to be in AWS anyway. I assume you didn’t mean keeping multiple copies of the backend and sync’ng the datastorage.
Looking into this.
FYI DNS entries added for openmrs.openconceptlab.org and openmrs.staging.openconceptlab.org. These should be in effect globally within an hour or 2.
Awesome, @paynejd
I finished the production one, it seems to be working (I can at least login).
But I didn’t create the staging one. Is that something we want to do?
Hi Cintia, let’s please add to staging also. Thank you!
I will do it tomorrow then 
I wasn’t necessarily suggesting AWS, but if the server pages were hosted locally I thought we’d run into problems with bandwidth and latency. In the future, more of the OpenMRS-OCL actions need to be performed in the cloud and not back on the browser. For now, that is the way it is written. Actually @paynejd, I am not sure where the main OCL is hosted 
Perhaps the confusion is that nairobi is the name of a server, not actually a server located in the city in Kenya.
There is no need to change anything about the application/hosting architecture at this point. The html/css/js application can be hosted anywhere in OpenMRS’s available server space, presumably alongside the OCL backend.
Thanks for the clarification!!
Oh that explains a lot more.
Before my time, it was decided that we name server as city names from Malawi, Cameroon and Kenya. I just added Malawi to the mix to have a few more options. I made an exception for CI/Bamboo agents.
You can see all servers in this autogenerated doc or github
Our all servers are on Jetstream. Both datacenters are in US.
Both OCL backend and OCL client are being served from the same machine, nairobi, as the doco would show the DNS.
Build is green @cintiadr
@c.antwi @akanter @darius @karuhanga @dkayiwa @herbert24 @cintiadr , does this imply we have the MVP completed ,and can now be used in production with our OCL subscription module ?
Thanks
Moses
Ref app 2.10 release manager
I don’t know. From the infrastructure point of view, it’s as done as needed. From the project point of view, I have no idea.
thanks @cintiadr for the sincere reply 
@mozzy let us proceed as time is not on our side
I’d like some input from @akanter and @darius, but I believe the only pending thing at this point is making sure that CIEL points to a released version. A released version of CIEL is now up, but I am still following this up with @raff because it looked like some concepts and mappings were not being reflected after release.
@paynejd @raff @maurya could you provide feed back on @karuhanga question above?
@c.antwi this has now been addressed.
