<div dir="ltr">Hi Neil,<div><br></div><div>The "master election" process for schedulers is not perfect for me. It would need a bit more work in order to really be up to date with state of the art master election best practices.<br>So indeed, I would at the moment advice the have a single master doing the schedulers.</div><div><br></div><div>For example:</div><div><a href="https://docs.google.com/presentation/d/1CA932aTgicnOpIReOhZcqijHE9BGapXfpkIqx9nSRnw/edit#slide=id.g2219c85b58_1_532">https://docs.google.com/presentation/d/1CA932aTgicnOpIReOhZcqijHE9BGapXfpkIqx9nSRnw/edit#slide=id.g2219c85b58_1_532</a></div><div><br></div><div>Scality have a single "frontend" master which is doing the www and schedulers, and hooks. This is not a "HA" setup, but anyway buildbot scheduler election has a 10min recovery timer for when a master fail.</div><div><br></div><div>As for claims and collapsing, we have found recently some annoying bugs about those:</div><div><a href="https://github.com/buildbot/buildbot/pull/3411">https://github.com/buildbot/buildbot/pull/3411</a></div><div><a href="https://github.com/buildbot/buildbot/pull/3152">https://github.com/buildbot/buildbot/pull/3152</a></div><div> <br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 5, 2017 at 6:20 PM Neil Gilmore <<a href="mailto:ngilmore@grammatech.com">ngilmore@grammatech.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone.<br>
<br>
Well, now that I can (reliably) release locks though Twisted's manhole,<br>
things are a bit brighter. We have a somewhat rare problem in which all<br>
of a worker's builders are 'acquiring locks'. Doesn't happen often, but<br>
it keeps things from running. Remember, we can't use the worker<br>
configuration to limit builds.<br>
<br>
But we're having another problem that seems to be getting a bit worse. I<br>
seem to recall Pierre saying that in a multi-master configuration, if<br>
there was a scheduler that existed on multiple masters, that scheduler<br>
would only be active on a single master. Other masters might activate<br>
that scheduler if the first master went away. So there should only be<br>
one master's scheduler scheduling particular builds.<br>
<br>
Well, that isn't happening for us. It's not a problem most of the time,<br>
because the builds do collapse, most of the time. Except when they don't.<br>
<br>
For example, last weekend we had 3 builds schedule and build for the<br>
same sourcestamp (according to the debug information in the UI). The<br>
builds were scheduled within 3 seconds of each other. However, they were<br>
claimed many hours apart. It appears that the first build completed<br>
before the second was claimed, etc. Is this how it ought to go? I<br>
haven't quite cracked the submitted/claimed/started timing.<br>
<br>
We had a similar claiming problem last week where a build went unclaimed<br>
for 44 days. So when it popped up. it appeared that we had gone back in<br>
time (as the revision was quite old at that time).<br>
<br>
Do I just need to figure out how to not put schedulers on more than 1<br>
master?<br>
<br>
Neil Gilmore<br>
<a href="http://grammatech.com" rel="noreferrer" target="_blank">grammatech.com</a><br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@buildbot.net" target="_blank">users@buildbot.net</a><br>
<a href="https://lists.buildbot.net/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.buildbot.net/mailman/listinfo/users</a><br>
</blockquote></div></div></div>