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