tasks in waiting mode
by Jean-Marc Liger
Hi,
There are 142 tasks in waiting mode while only 7 tasks are running.
Regards,
Jean-Marc
7 years, 7 months
Re: New Release!
by Pavel Raiskup
On Tuesday, September 6, 2016 10:18:31 AM CEST Michal Novotny wrote:
> On Tue, Aug 30, 2016 at 7:43 AM, Pavel Raiskup <praiskup(a)redhat.com> wrote:
>
> > On Tuesday, August 30, 2016 7:39:14 AM CEST Pavel Raiskup wrote:
> > > Currently it looks like such error-handling is not implemented anyway,
> > > we drop the build and it is re-submitted after some deadline.
> >
> > By "drop" here I mean that the build simply fails on BE, while it is still
> > in "running" state in FE databse. That build is put in queue once again
> > after MAX_BUILD_TIMEOUT.handling non-responsive VMs.
>
> But that's different from the (primitive) deferring mechanism where
> backend takes any job that frontend feeds it with and returns it back
> (effectively saying "try to give me this job later") if it finds out the
> job cannot be handled at the moment.
Right, that's why I say that the actual deferring is not needed at all. Because
backend is not going to ask for build if it is not able to immediately handle
it.
> If you would like to use what you have described to implement
> "deferring", then I doubt you can fit it on that very well.
I don't follow here.
> I am satisfied with the current state and will implement more only
> if/when I find it insufficient (meaning "performing very badly") later
> but feel free to send us patches for this sooner if desired.
Now, slower architectures (ppc64le) will (a bit) delay the queues in faster
architectures (x86_64/i386). Or am I wrong here? Yes, it is not big issue.
But I just claim that the "major rewrite" (without code review!) reached
production too early, because it brings zero benefits. It would be beneficial,
and I could appreciate it, if it was 1:1 replacement, but so far it is not.
Please consider having simple "Pull-request -> LGTM -> merge" commit process.
Pavel
7 years, 7 months
Fwd: New Release!
by Michal Novotny
On Tue, Aug 30, 2016 at 7:43 AM, Pavel Raiskup <praiskup(a)redhat.com> wrote:
> On Tuesday, August 30, 2016 7:39:14 AM CEST Pavel Raiskup wrote:
> > Currently it looks like such error-handling is not implemented anyway,
> > we drop the build and it is re-submitted after some deadline.
>
> By "drop" here I mean that the build simply fails on BE, while it is still
> in "running" state in FE databse. That build is put in queue once again
> after MAX_BUILD_TIMEOUT.handling non-responsive VMs.
But that's different from the (primitive) deferring mechanism where backend
takes any job that frontend feeds it with and returns it back (effectively
saying
"try to give me this job later") if it finds out the job cannot be handled
at the moment.
If you would like to use what you have described to implement "deferring",
then I doubt you can fit it on that very well.
I am satisfied with the current state and will implement more only if/when
I find it
insufficient (meaning "performing very badly") later but feel free to send
us patches
for this sooner if desired.
>
> Pavel
>
>
7 years, 7 months
