Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate Current infrastructure to OpenShift #31

Closed
datagero opened this issue Oct 25, 2024 · 1 comment
Closed

Migrate Current infrastructure to OpenShift #31

datagero opened this issue Oct 25, 2024 · 1 comment

Comments

@datagero
Copy link
Owner

datagero commented Oct 25, 2024

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:

  • 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 (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 (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:

Dependencies:

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
Copy link
Owner Author

datagero commented Oct 25, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants