Project

General

Profile

Actions

action #126935

open

coordination #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

Promote /experimental/jobs/.../status as non-experimental API

Added by livdywan over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Feature requests
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Motivation

The /experimental/jobs/.../status lives in the experimental namespace. In some use cases it can replace /api/v1/jobs/... and be more efficient. However it's not well-known and not used much.

Acceptance Criteria

  • AC1: A non-experimental efficient job status route is available

Suggestions

  • Move the route out of the experimental namespace
  • Confirm what the route does, and that it's the best implementation
  • Consider other job routes that are frequently needed which we don't have yet?
  • Add documentation about how to use the route
  • Recommend use of the route in suitable channels going forward e.g. chat rooms, blog posts, talks
Actions #1

Updated by okurz over 1 year ago

  • Priority changed from Normal to Low
  • Target version set to Ready
Actions #2

Updated by osukup over 1 year ago

nice, It should be enough for openqa-mon, but unfortunately gem-bot needs more info from jobs:(

id ,group_id,group, clone_id are used by sync results step and parent_group + parent_group_id will be nice to eliminate another call to openqa api from qem-bot

Actions #3

Updated by tinita over 1 year ago

I think it would still be cheap to add those fields.
Compare the normal jobs/:id route:

SELECT me.id, me.result_dir, me.archived, me.state, me.priority, me.result, me.reason, me.clone_id, me.blocked_by_id, me.TEST, me.DISTRI, me.VERSION, me.FLAVOR, me.ARCH, me.BUILD, me.MACHINE, me.group_id, me.assigned_worker_id, me.t_started, me.t_finished, me.logs_present, me.passed_module_count, me.failed_module_count, me.softfailed_module_count, me.skipped_module_count, me.externally_skipped_module_count, me.scheduled_product_id, me.result_size, me.t_created, me.t_updated, settings.id, settings.key, settings.value, settings.job_id, settings.t_created, settings.t_updated FROM jobs me LEFT JOIN job_settings settings ON settings.job_id = me.id WHERE ( me.id = ? )  ORDER BY me.id: '3180131'
SELECT me.id, me.result_dir, me.archived, me.state, me.priority, me.result, me.reason, me.clone_id, me.blocked_by_id, me.TEST, me.DISTRI, me.VERSION, me.FLAVOR, me.ARCH, me.BUILD, me.MACHINE, me.group_id, me.assigned_worker_id, me.t_started, me.t_finished, me.logs_present, me.passed_module_count, me.failed_module_count, me.softfailed_module_count, me.skipped_module_count, me.externally_skipped_module_count, me.scheduled_product_id, me.result_size, me.t_created, me.t_updated FROM jobs me WHERE ( me.clone_id = ? ): '3180131'
SELECT me.job_id, me.asset_id, me.created_by, me.t_created, me.t_updated FROM jobs_assets me WHERE ( me.job_id = ? ): '3180131'
SELECT me.id, me.type, me.name, me.size, me.checksum, me.last_use_job_id, me.fixed, me.t_created, me.t_updated FROM assets me WHERE ( me.id = ? ): '66876051'
SELECT me.child_job_id, me.parent_job_id, me.dependency FROM job_dependencies me WHERE ( me.child_job_id = ? ): '3180131'
SELECT me.child_job_id, me.parent_job_id, me.dependency FROM job_dependencies me WHERE ( me.parent_job_id = ? ): '3180131'

which does 6 SELECTs, to the current status route:

SELECT me.id, me.result_dir, me.archived, me.state, me.priority, me.result, me.reason, me.clone_id, me.blocked_by_id, me.TEST, me.DISTRI, me.VERSION, me.FLAVOR, me.ARCH, me.BUILD, me.MACHINE, me.group_id, me.assigned_worker_id, me.t_started, me.t_finished, me.logs_present, me.passed_module_count, me.failed_module_count, me.softfailed_module_count, me.skipped_module_count, me.externally_skipped_module_count, me.scheduled_product_id, me.result_size, me.t_created, me.t_updated FROM jobs me WHERE ( me.id = ? ): '3180131'

And now looking at that, that seems even wrong.
When I added that route, I only did a select on 4 fields. But later it was changed to select all fields, but only return those 4 fields in JSON :(
And it was actually me who did that change. That should be easy to fix.

Actions #4

Updated by tinita over 1 year ago

There was also the idea of @kraih to add a batch route, fetching x jobs with one API call & one SELECT, which I also think makes sense.

Actions #5

Updated by okurz over 1 year ago

  • Target version changed from Ready to future
Actions

Also available in: Atom PDF