[Buildbot-devel] Why slaves locked by a builder lock are considered as available by this builder

[John Carr]

That might not be entirely true anymore:

https://github.com/buildbot/buildbot/commit/40dbc48a61f18935e4b907574661af91da504d44

This allows locks passed to the Slave definition to be acquired before builds can happen on that slave and allows them to be rescheduled on other slaves if the locks can't be acquired.

It was a key part of making libvirt integration work nicely, but i've completely forgotten why!

John


On 18 Feb, 2012,at 04:17 PM, "Dustin J. Mitchell" <dustin at v.igoro.us> wrote:

So, the problem with slavelocks is that they are acquired *after* a
build is begun, and they simply block the build if the lock is already
held by another build, rather than re-trying to distribute the
buildrequest, possibly to another slave. SlaveLocks are good for
locking around a particular *step* -- say, around a step that uses the
database instance hosted on the slave to run some tests -- rather than
for the entire build.

Generally, the best way to limit parallelism is with the maxBuilds
slave argument, as this is checked before a build is started.

Dustin

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Buildbot-devel mailing list
Buildbot-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/buildbot-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20120218/6a6005d8/attachment.html>