On Tuesday, September 6, 2016 10:18:31 AM CEST Michal Novotny wrote: > On Tue, Aug 30, 2016 at 7:43 AM, Pavel Raiskup <[email protected]> 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 _______________________________________________ copr-devel mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected]
