Project

General

Profile

Actions
Copy link

action #103317

closed

No time visible in scheduled jobs

Added by livdywan about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Low
Assignee:
mkittler
Category:
Feature requests
Target version:
QA (public) - future
Start date:
2021-11-30
Due date:
% Done:

0%

Estimated time:

Description

Observation

I'm cloning several jobs, which are run within a few minutes. The next job is sitting there longer, for example 30 minutes, but I can't tell from the job details so long as it's in the "scheduled" state. See also the attached screenshot.

Results for opensuse-Tumbleweed-NET-x86_64-Build20211129-textmode@64bit
State: scheduled 
Scheduled product: job has not been created by posting an ISO
 50 
Installation in textmode and selecting the textmode "desktop" during installation.

Note: The activity also doesn't show the time for scheduled jobs.

Work-around

  • Use the "All tests" view.
  • Type e.g. Build20211129 in the filter view of "scheduled" tests

Files

scheduled-details.png (18.5 KB) scheduled-details.png job details, schedule, no time visible livdywan, 2021-11-30 12:18
Actions
Copy link
 #1

Updated by okurz about 3 years ago

  • Category set to Feature requests
  • Priority changed from Normal to Low
  • Target version set to Ready

so you would want something equivalent to the "running, started X minutes ago", like "scheduled, waiting since X minutes"?

Actions
Copy link
 #2

Updated by livdywan about 3 years ago

okurz wrote:

so you would want something equivalent to the "running, started X minutes ago", like "scheduled, waiting since X minutes"?

Yeah. On "All tests" the table header says "Created" so maybe "scheduled, created X minutes ago" would be consistent. Although I'd slightly prefer "scheduled X minutes ago" and rename the table header.

Actions
Copy link
 #3

Updated by okurz about 3 years ago

  • Target version changed from Ready to future

Proposal sounds good. Sorry, wanted to put this into future. As this is not critical we should not immediately pick up newer reports over older ones that still wait.

Actions
Copy link
 #4

Updated by asmorodskyi about 3 years ago

I think this functionality will ease detection of freeze jobs . +1

Actions
Copy link
 #5

Updated by coolgw about 3 years ago

very useful feature!
Can we also show how many jobs is in backlog now (not schedule yet) or how long it will wait for run.
BTW: if we can adjust priority automatic in case waiting too long?

Actions
Copy link
 #6

Updated by okurz about 3 years ago

coolgw wrote:

Can we also show how many jobs is in backlog now (not schedule yet)

good idea. I envision a message like `scheduled (since about 2 hours, 1234 jobs in the queue for the same worker class)

or how long it will wait for run.

Well, we can't give a guarantee but we could estimate how long it took for jobs in the same worker class in the past

BTW: if we can adjust priority automatic in case waiting too long?

well, that depends on what is "too long" and how to adjust priorities. Currently we use AFAIK a prioritized FIFO queue, i.e. as long as there are no jobs with higher priority in the same worker class then the oldest one will be executed first. How would you expect an automatic priority change impact that?

Actions
Copy link
 #7

Updated by mkittler almost 3 years ago

  • Assignee set to mkittler

This PR shows the creation date (in the usual way, e.g. "3 hours ago"): https://github.com/os-autoinst/openQA/pull/4488

Not sure whether it is good enough considering the other ideas.

Actions
Copy link
 #8

Updated by mkittler almost 3 years ago

  • Assignee deleted (mkittler)
Actions
Copy link
 #9

Updated by okurz almost 3 years ago

  • Status changed from New to Resolved
  • Assignee set to mkittler

I added the not yet implemented part to #65271 so that we can conclude the part about scheduled time here. Trying to keep it both in the same ticket could be cause more confusion than it would help.

Actions
Copy link

Also available in: Atom PDF