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

[Pierre Tardy]

>
>
> 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
restart.

>
> 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
Cheers,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildbot.net/pipermail/users/attachments/20161202/4fc1766d/attachment.html>