Migrate Current infrastructure to OpenShift

[datagero]

Objective:
Migrate the entire application infrastructure to OpenShift, ensuring all services and components are containerized, deployed, and operational in a Kubernetes environment.

Details:

• Containers and Registry Setup:

  • Set Up Private/Public Container Registry:
  • Ensure all containers are stored securely in a private registry on OpenShift or a compatible registry service.
  • Track in Set Up Private/Public Container Registry in OpenShift (#34).

• Database Migration:

  • Migrate MySQL to TiDB:
  • Replace the current non-persistent MySQL database with TiDB for scalability and persistence.
  • Handle query logic updates for seamless data access.
  • Track this in Migrate MySQL to TiDB (#36).

• Application Containers Migration:

  • Backend Container Migration:
  • Move the backend (FastAPI, AI NLP services, including RAG logic) into an OpenShift service.
  • Ensure connections to the TiDB cluster and OpenAI API are established.
  • Track this in Migrate Frontend and Backend Dockerfiles to OpenShift (#33).
  • Frontend Container Migration:
  • Deploy the existing frontend container to OpenShift, ensuring it communicates with the backend service.

• Deployment and Configuration:

  • Deploy Containers in Kubernetes:
  • Ensure proper service discovery, load balancing, and scaling via OpenShift.
  • Use Write OpenShift Deployment Manifests for Frontend and Backend Services (#37) to ensure correct deployment.
  • Optional:
  • Expose endpoints to the internet with appropriate security measures.

Dependencies:

• #34: Set Up Private/Public Container Registry in OpenShift
• #36: Migrate MySQL to TiDB
• #33: Migrate Frontend and Backend Dockerfiles to OpenShift
• #37: Write OpenShift Deployment Manifests for Frontend and Backend Services

Acceptance Criteria:

• All services and components are migrated to OpenShift and deployed as Kubernetes services.
• Backend services connect to the TiDB cluster and OpenAI API successfully.
• Frontend and backend containers communicate seamlessly.
• Optional endpoints are exposed with proper security, if required.

Priority:
P0 (Critical)

Estimated Effort:

[datagero]

raw notes for additional considerations:

P0 Ticket: Reference #19 (currently blocked) - Until the open-source LLM (e.g., LLaMA 3.1) can be deployed, all RAG and query-related services will operate in LLM-free mode.

---

Draft Future Ticket – Refactor Architecture for Modularity and Efficiency (P1)

This refactor aims to package shared backend logic—specifically our interfaces (e.g., IndexInterface, QueryInterface, DatabaseInterface)—into a reusable Python package to be consumed by multiple microservices. This approach will improve maintainability, ensure consistent functionality, and streamline future development.

An API Gateway will be implemented to manage communication between the frontend and these microservices, ensuring seamless interaction and scalability. This refactor will follow the OpenShift migration, with tasks focused on packaging the interfaces and deploying the API Gateway to enable a modular architecture.