[users at bb.net] More anecdotes from the multi-master trenches.

Pierre Tardy tardyp at gmail.com
Fri Dec 2 20:05:09 UTC 2016

> Now I'm seeing some odd anomalies. [..]
> Could this be part of the result of schedulers not being particularly
> reconfigurable?
I'd guess so. Probably that big change would deserve a scheduled master

> And on that note, there seems to be 3 schemes in 0.9.x for
> checkConfig/reconfigService.
> Number 1 is how the schedulers do it. Which is that they don't, but have
> largish __init__() functions.
> Number 2 is how the workers do it. checkconfig looks a lot like __init__
> might, and reconfigService looks a lot like checkConfig, except that it
> doesn't except.
It is possible that the code working with workers needs to have some of the
worker attribute set before they are fully configured. I guess this is the
reason why the checkconfig sets attributes... Or this is a confusion. would
need to remove those and see what breaks.

This is not bad though, it is just code duplication, as those attribute
needs to be set in reconfig anyway.

> Number 3 is how things like reporters do it. checkConfig only does
> checks (and the occasional null-ish initialization), and reconfigService
> copies its arguments into itself.
This is how it is meant to be used.

> One slightly happier anecdote...
> We ended up with a situation where there were 2 builders for a
> particular worker. Both had current builds marked as acquiring locks
> (remember that we use locks to keep it to one build per worker, except
> for a special builder that should always run, even if there's another
> build running. That's why we don't restrict builds at the worker level).
> I did manage to go in through the manhole and release the lock from
> whoever was holding it. By the time I got far enough to do that, I
> wasn't interested in figuring out which build was actually holding onto it.

Manhole is cool for such hacks.. but its being removed in recent twisted.

Thanks for you feedbacks and return of experience. I think they are quite
useful for the community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20161202/4fc1766d/attachment.html>

More information about the users mailing list