Community Bonding Update
Hi everyone!
Now that the official coding phase kicked off, I want to share a recap of what has been happening behind the scenes during the Community Bonding period.
My mentor @raff and I used this time to align on the technical roadmap and architecture. We dove straight into the code to clear out legacy infrastructure blockers and lay down the foundational architectural pieces so that true horizontal scaling can happen smoothly.
Here is a breakdown of the milestones and pull requests (PRs) we have already successfully achieved and merged across our primary project repositories:
What’s Been Done So Far
-
Mentor Alignment & Architectural Reviews: Held productive sync session to align on our implementation strategies, review the overall scope, and establish a clear development pipeline for the weeks ahead.
-
Built and Published Custom Elasticsearch Image (openmrs-contrib-elasticsearch PR #1): To support cluster-wide search functionalities natively, I built a custom Dockerfile that pre-installs the
analysis-phoneticplugin. I also wired up a GitHub Actions workflow to automatically publish this image to Docker Hub. This has already been successfully reviewed and merged! Credit to @ibacher for the guidance on this. -
Eliminated Startup Crash-Loops (openmrs-contrib-cluster PR #10): I resolved a critical race condition where application servers would crash-loop if they tried to boot up before the background search index cluster was fully ready. By introducing smart readiness checks, the servers now wait patiently, paving the way for safe, automated scaling (HPA).
-
Upgraded to the Official MariaDB Operator (openmrs-contrib-cluster PR #9): We completely ripped out legacy database blueprints and replaced them with a cutting-edge MariaDB Galera cluster. Database scaling is now entirely automated; the system natively supports synchronous data replication across multiple active database nodes.
-
Migrated to the Official Elastic Operator (openmrs-contrib-cluster PR #8): To ensure search operations scale smoothly, we moved search management over to the official enterprise operator, migrating from legacy Bitnami blueprints. This upgrade enforces secure, encrypted communications by default and allows implementations to split up heavy search workloads onto dedicated servers.
What’s in the Pipeline (Current Work)
-
Modern Routing via Traefik & Gateway API (openmrs-contrib-cluster PR #12 - Open): Right now, I am actively working on replacing the old network routing setup with the modern Kubernetes Gateway API powered by Traefik v3. This will cleanly isolate traffic management from our application code, unlocking capabilities for safer software updates (like Canary or Blue/Green rollouts).
-
Re-architecting Shared Storage & Migrating from MinIO: I am currently evaluating a critical transition for our S3 object storage layer. Because the open-source community track for MinIO has been frozen and permanently archived, it introduces long-term security debt and unpatched vulnerabilities. To solve this, I am actively exploring and gathering community feedback on replacing it with a secure, highly active, and lightweight alternative, specifically SeaweedFS or Rook/Ceph to serve as our new unified, S3-compatible cloud storage engine.
Blockers & Next Steps
Fortunately, there are no blockers! The community bonding period has been incredible for aligning closely with my mentors and landing these prerequisite building blocks.
As we transition into the core coding phase, my immediate next steps are:
-
Finalizing and merging the modern routing updates.
-
Resolving the S3 object storage migration based on community and mentor feedback.
-
Beginning formal load-testing to calibrate automated scaling rules for the core application servers.
A huge thank you to my mentor @raff for the stellar guidance, technical alignment, and rapid code reviews so far.