Comment 11 for bug 393546

Revision history for this message
Michael Nelson (michael.nelson) wrote :

Just some initial planning/investigation: currently the BuilddManager.scan() iterates each builder, and effectively for each idle builder it calls builder.findBuildCandidate() - and if it finds *one* - dispatches it.

So, afaics, the main issue for implementing the above is that we have all our builders picking single builds off the one primary build queue, where as it would be handy to have instead individual queues for each builder and dispatch a set of builds from the primary queue to the individual builder queue.

Eventually I think it would be great to utilize a messenging system (RabbitMQ - where are you?) to do the above, but in the mean time, another possible solution might be to have a new build-state in between NEEDSBUILD and BUILDING - perhaps BUILDER_ASSIGNED. During builder.findBuildCandidate() - in addition to returning the next build - we could set the status of all the other builds of same priority for the same SPR.creator (? hrm... uploader?), assign the builder and set the BuildStatus.BUILDER_ASSIGNED. Subsequent calls to builder.findBuildCandidate() would always find and dispatch the assigned builds first before checking the general queue again?

Actually, as a slight improvement, the builder would first check if there are any *higher* priority builds in the build queue (and there are a number of options for what it could do if one/some are found, fairest probably being to reset existing assigned builds to NEEDSBUILD).

This behaviour in IBuilder.findBuildCandidate() would have to be optional, as I assume we would *not* want this behaviour for urgent builds (eg. security). There are a number of ways we could make it optional - ppa setting, or a priority threshold etc.

Thoughts?