[users at bb.net] One anecdote, and some unsolicited code.

[Neil Gilmore]

Hi everyone,

The anecdote first.

So we've been plagued with the non-modifiable scheduler problem. A lot. 
I finally got to look at that without distraction yesterday. 
Unfortunately, I didn't find the documentation on the reconfiguration 
process too useful other than to point me at function names. I did find 
that spelunking through the code and adding some timely logging helped. 
I added logging to BuildbotService.checkconfig() and 
BuildbotService.reconfigService().

Using master.cfg.sample, though I got some unexpected results. Looking 
through the docs, I expected to see both the 'all' and 'force' 
schedulers configure the first time. However, the 'force' scheduler then 
tried to reconfigure. And this continued. If I subsequently did a 
reconfig, using the same master.cfg, the 'all' scheduler would not 
attempt to reconfigure, but the 'force' scheduler would. I'm pretty sure 
it's not supposed to.

Thus endeth the anecdote.

Now for the unsolicited code.

So I first wrote an overriden version of reconfigService() in 
BaseScheduler. Goody! When I start or reconfig, my version gets called. 
But I really didn't want to have to create _config_args and 
_config_kwargs in BaseScheduler. It looked safe to override 
reconfigServiceWithSibling in BaseScheduler. It's nice that all the 
figuring out whether to reconfig or not is already computed by that 
point. The resulting function is all of 9 lines:

(in class BaseScheduler)
     def reconfigServiceWithSibling(self, sibling):
         # only reconfigure if sibling is configured differently.
         # sibling == self is using ComparableMixin's implementation
         # only compare compare_attrs
         if self.configured and sibling == self:

             return defer.succeed(None)
         self.configured = True
         self.name = sibling.name
         self.builderNames = sibling.builderNames
         self.properties = sibling.properties
         self.codesbases = sibling.codebases
         return defer.succeed(None)

I couldn't say whether this will have the old fix's problem of messing 
up triggerable builds, but I don't think so, as I'm keeping the same 
instance. Nor am I certain that only reconfiguring the fields in 
compare_attrs is correct.

But it worked for me. Using master.cfg.sample, I changed the scheduler 
from SingleBranchScheduler to Periodic, times at a minute. Started a new 
master, and determined that it was indded scheduling a build every 
minute (I didn't have a worker running, figuring that if I was 
scheudling, it was good enough). I then edited my master.cfg to add a 
second builder, just like runtests, named runtests2. And add it to the 
'full' scheduler. Then I did a reconfig. Sure enough, the second builder 
showed up and started scheduling builds. I then did the same with 
runtests3. And again, I was getting builds scheduled.

Are there any gotcha's with this function? Anything I missed?

(I know it's not in the form of a patch or anything, but if it helps 
anyone, got ahead and use it).

Neil Gilmore
grammatech.com