action #119428
opencoordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes
coordination #92854: [epic] limit overload of openQA webUI by heavy requests
action #97190: Limit size of initial requests everywhere, e.g. /, /tests, etc., over webUI and API
Ensure users can get all the data for limited queries, e.g. with pagination
56%
Description
Acceptance criteria¶
- AC1: For every query or API route there is a way for users to get all the data, e.g. with pagination
- AC2: By default we still show a sensible number
Suggestions¶
- Wait for outcome of #114421
- Allow users to get all data but each query limited
- Optional: UI elements to configure the limit directly
- As an example for introducing a limit, have a look at https://github.com/os-autoinst/openQA/commit/4242bb107e032c27d5f99c91a358adc9640f5ca6
Updated by okurz about 2 years ago
- Copied from action #114421: Add a limit where it makes sense after we have it for /tests, query configurable size:M added
Updated by okurz about 2 years ago
- Priority changed from Low to High
- Target version changed from future to Ready
This is actually getting more important due to the "regressions" that users can not get all results anymore, e.g. see https://suse.slack.com/archives/C02CANHLANP/p1668584467225009
Updated by okurz about 2 years ago
- Priority changed from High to Low
- Target version changed from Ready to future
scratch my last, handling in #120315
Updated by kraih about 2 years ago
- Assignee set to kraih
After #120841 is done and we have an example for how to implement the feature properly, i went through all the limit settings to make a list of other endpoints that need pagination:
generic_default_limit, generic_max_limit:
* GET /api/v1/bugs
* GET /api/v1/jobs/<job_id:num>/comments (messy code)
* GET /api/v1/jobs
* GET /api/v1/test_suites, GET /api/v1/test_suites/:id, GET /api/v1/machines, GET api/v1/machines/:id, GET /api/v1/products, GET /api/v1/products:id (shared code)
* GET /api/v1/workers
* GET /tests/list_scheduled_ajax
tests_overview_max_jobs:
* GET /tests/overview
all_tests_default_finished_jobs, all_tests_max_finished_jobs:
* /tests/list_ajax
list_templates_default_limit, list_templates_max_limit:
* GET /api/v1/job_templates
next_jobs_default_limit, next_jobs_max_limit, previous_jobs_default_limit, previous_jobs_max_limit:
* GET /tests/<testid:num>/ajax
job_settings_max_recent_jobs:
* GET /api/v1/job_settings/jobs (moving search window, tricky)
assets_default_limit, assets_max_limit:
* GET /api/v1/assets (already done)
search_results_limit (setting is in a different group):
* GET /experimental/search
Updated by kraih about 2 years ago
I'll add all the necessary tickets for subtasks.
Updated by kraih about 2 years ago
I've created linked subtasks for all API endpoints now. On Oliver's request i've put them into future.
Updated by kraih about 2 years ago
- Status changed from In Progress to Blocked
This ticket is now blocked on all the subtasks.
Updated by kraih almost 2 years ago
- Related to action #119431: Inform users e.g. in the webUI if not all results are returned size:M added
Updated by okurz over 1 year ago
- Status changed from Blocked to New
- Assignee deleted (
kraih) - Target version changed from Ready to future
Currently no subtasks are in the backlog, removing