Feature changed by: Glenn Doig (doiggl)
Feature #306948, revision 7
Title: Estimation on waiting time on a package on obs
Buildservice: Unconfirmed
Priority
Requester: Important
Requested by: Glenn Doig (doiggl)
Description:
Hello, When your project is blocked in the queue because it is waiting
for something to build e.g(binutils) can a time estimate be given as to
how long to wait before it may start processing - put that estimation
on the 'Package AAA (Project BBB home:CCC)' page when you view the
page. Example: (Packages waiting queue * Average Job time) + (Your
package Nth position in the Packages blocked queue * Average Job time )
= value Put that value in the package page. Some details used from
https://build.opensuse.org/monitor It would be nice to know when your
package may start to process. Cheers Glenn Responses so far sourced
from http://lists.opensuse.org/opensuse-buildservice/2009-07/msg00235.html
One could implement something, but it will not be very reliable,
because the state and order can change with any further submission. >
Adrian
and
I suggest to file a feature request using features.opensuse.org. But
first:What to others think? Do you consider such an estimate ok?
Or should we not publish anything since it might change too often? >
Andreas
Discussion:
#1: Stephan Binner (beineri) (2009-07-24 12:43:23)
There is no "Nth position in blocked queue" and also no "Nth position
in scheduled queue" as the scheduler randomly picks one out of it -> no
estimation calculation possible.
#2: Glenn Doig (doiggl) (2009-07-24 14:38:08)
Another comment from
http://lists.opensuse.org/opensuse-buildservice/2009-07/msg00241.html
From: Vincent Petry Date: Fri, 24 Jul 2009 20:00:36
+0800 Message-id: <4A69A264.9020101@xxxxxxxx> Hi, I think it depends
how much the estimation is wrong. If it says 10 minutes when it's 6
hours, I think it's not good. But if it says like 1 hour when it's 2,
it might still be ok. At least it can help someone to decide whether
it's worth waiting a few minutes/hours, or simply give up and check the
next day. The time estimation for one package could be based on
heuristics from its compile time history. For example, if after
compliling a given package a few times we found out that it usually
takes say 30 minutes to build successfully, then we can assume that in
the future it will take almost as long, if not longer. Also like Doiggl
said, it would be also good to know how many packages are in the queue.
A value like "5234 packages scheduled to be built before yours, 1234
currently building" might do it.
Vincent
#3: Vincent Petry (pvince81) (2009-07-24 15:49:57)
If the scheduler gets improved in the future, this estimation feature
might be possible.
#4: Glenn Doig (doiggl) (2009-07-30 05:01:35)
Its impossible to tell where your job is, but your job is 'scheduled'.
It would be nice to know where in the queue it is. I guess people would
like to know where there job is in the 'blocked' que if your job is
blocked. Host Arch x86_64 Packages in waiting queue 1027 Packages in
blocked queue 15420
Average Job time 31 minutes
+ #5: Glenn Doig (doiggl) (2009-08-01 02:52:46)
+ some more info from ->
+ http://lists.opensuse.org/opensuse-buildservice/2009-07/msg00302.html
+ Re: [opensuse-buildservice] BS monitor does not show all scheduled
+ jobs * From: * Date: Fri, 31 Jul
+ 2009 19:39:22 +1000 * Message-id:
+ <674580bb0c949eff789615430df8ed36@xxxxxxxxxxxxxxxxxxxxxxx> Hello Thanks
+ Dominique, is there any possibility of utilizing the idle hosts to help
+ out even though it is a different platform e.g ppc64 [37 out of 197]
+ https://build.opensuse.org/monitor Cheers Glenn Dominique
+ wrote The only way to reduce the waiting time is throwing more
+ build power at it. If you have 200 packages, each taking 30
+ minutes to compile, it's going to take 100 hours, no matter in what
+ order you build them. Except in the rare case that all packages are
+ waiting for a single build (example gcc). But then, this also won't
+ change, as it would block everything else, anyhow it's 'the only'
+ possibility to start with, as everything is blocked. So in
+ short: I guess to get shorter cycles, just more build hosts need
+ to be connected. (which of course summarizes down to somebody
+ needing to throw money in). A 'distributed' approach might be
+ interesting, but I understand that the question of trusting RPMs
+ built in such a way would be very very high up on the list (no
+ guarantee a remote worker is not tampering the created RPMs).
+ Dominique
--
openSUSE Feature:
https://features.opensuse.org/306948