Actions
action #126941
openopenQA Project (public) - coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes
openQA Project (public) - coordination #92854: [epic] limit overload of openQA webUI by heavy requests
[spike] Evaluate a move of the osd database to its own VM
Start date:
2023-03-30
Due date:
% Done:
0%
Estimated time:
Tags:
Description
Motivation¶
With the database split out the total load could be managed better.
Acceptance Criteria¶
- AC1: Benefits of running the openQA database on a dedicated host are known
Suggestions¶
- Confirm the effort and impact of using another VM to host the database
- Evaluate the current side-effects of openQA and postgres running on the same host e.g. hard limits on the VM host we can use
Updated by okurz almost 2 years ago
- Tags set to infra
- Project changed from openQA Project (public) to openQA Infrastructure (public)
- Priority changed from Normal to Low
- Target version set to future
I would do this if we know that the database execution is a significant contributor. How about you rephrase it to evaluate if that move would help?
Updated by livdywan almost 2 years ago
- Subject changed from Move the osd database to its own VM to [spike] Evaluate a move the osd database to its own VM
- Description updated (diff)
Updated by livdywan almost 2 years ago
- Subject changed from [spike] Evaluate a move the osd database to its own VM to [spike] Evaluate a move of the osd database to its own VM
Updated by nicksinger about 2 months ago
- Copied to action #170365: Understand and eventually correct why enginfra thinks we're using their mysql cluster added
Actions