Project

General

Profile

Actions
Copy link

coordination #164466

open

[saga][epic] Scale up: Hyper-responsive openQA webUI

Added by okurz 1 day ago. Updated 1 day ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
future
Start date:
2024-07-26
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)

Subtasks 13 (13 open — 0 closed)

openQA Infrastructure - coordination #164469: [epic] Better tools team incident handlingNew2024-07-26

Actions
action #164481: [tools] Discuss benefits vs. drawbacks about applying mitigations as early as possible vs. keeping system in broken state to ease investigation. Also do industry standards best practice researchNew2024-07-26

Actions
openQA Infrastructure - action #164484: [tools] Investigation helper, e.g. commands in a bash script to collect useful logs, systemd journal, etc.New2024-07-26

Actions
openQA Infrastructure - action #164487: [tools] Research about a status page or maintenance fallback mode information page which we could redirect to. That could be known issues on openQA itself as well as redirect on the level of the web proxyNew2024-07-26

Actions
openQA Infrastructure - action #164490: [tools] We need to find a way to remind us about the process which we gave ourselves: How about a checklist that could be followed based on what's already mentioned in https://progress.opensuse.org/projects/qa/wiki/Tools#Process ?New2024-07-26

Actions
openQA Infrastructure - coordination #164514: [epic] Improved osd responsivenessNew2024-07-26

Actions
openQA Infrastructure - action #164472: Access log statisticsNew2024-07-26

Actions
openQA Project - action #164475: Optimize performance bottlenecks based on access log statistics which requests take longest or are heavyNew2024-07-26

Actions
openQA Infrastructure - action #164478: Monitoring of idle/busy webUI/liveview handler workersNew2024-07-26

Actions
openQA Infrastructure - action #164493: [tools] Research the meaning and implications of the number of workers as a tuning parameter. Come up with an understanding on how to select the value, where the limits are, what suggestions to openQA admins are -> add that in openQA documentationNew2024-07-26

Actions
openQA Infrastructure - action #164496: [tools] Follow-up on A4-1 but select a value dynamically based on nr. of requests vs. available system resourcesNew2024-07-26

Actions
openQA Infrastructure - action #164499: [tools] Limit the number of live views handled and present a "busy" message to users when there are no more free liveview handler workers availableNew2024-07-26

Actions
openQA Infrastructure - action #164502: [tools] Investigate if there are more potentially long running blocking requests which should be treated similar as the live view ones, i.e. being handled by a different process (group)New2024-07-26

Actions

Related issues 1 (1 open — 0 closed)

Copied from openQA Project - coordination #110833: [saga][epic] Scale up: openQA can handle a schedule of 100k jobs with 1k worker instancesNew2022-05-09

Actions
Actions
Copy link

Also available in: Atom PDF