Opened 7 years ago

Last modified 3 years ago

#2237 assigned enhancement

Schedulers should have names and reconfigService methods

Reported by: dustin Owned by:
Priority: minor Milestone: 0.9.+
Version: Keywords: reconfig, sprint
Cc:

Description

Rather than using comparableMixin to try to figure out if schedulers are "the same", Buildbot should use scheduler names. And the schedulers which remain present before and after a reconfig should get reconfigService called to look at any config changes.

Change History (13)

comment:1 Changed 7 years ago by dustin

  • Keywords reconfig added; github removed

comment:2 Changed 6 years ago by dustin

  • Milestone changed from 0.8.+ to 0.9.0

We'll need this in nine when schedulers get entries in the 'schedulers' table.

comment:3 Changed 6 years ago by dustin

  • Keywords sprint added

comment:4 Changed 6 years ago by dustin

  • Resolution set to fixed
  • Status changed from new to closed

comment:5 Changed 6 years ago by keeper

Hi Dustin,

This is not fixed already. commit which you linked explicitly says about it:

Schedulers are still stopped and re-started at every reconfiguration;
this may be changed in the future.

This problem is seen in configurations with many triggered builders. Once reconfiguration is done - builder which triggered another build and waits for finish will be aborted.

comment:6 Changed 6 years ago by dustin

  • Resolution fixed deleted
  • Status changed from closed to reopened

You're right, that only half-fixed the problem:

+        # find any schedulers that don't know how to reconfig, and, if they
+        # have changed, add them to both removed and added, so that we
+        # run the new version.  While we're at it, find any schedulers whose
+        # fully qualified class name has changed, and consider those a removal
+        # and re-add as well. 

So, schedulers with a reconfigService method won't get removed and re-added, but so far none of the schedulers have such a method.

comment:7 Changed 6 years ago by dustin

Thanks for calling me out on that error, by the way!

comment:8 Changed 5 years ago by dustin

  • Status changed from reopened to assigned

comment:9 Changed 5 years ago by tardyp

  • Priority changed from major to minor

put priotity to minor, as I think this is not fundamental. the current solution looks acceptable (feel free to disagree and put it back major)

comment:10 Changed 4 years ago by stibbons

I really suggest to move the reconfiguration method into each service, so by a dedicated method. It's up to the service itself to handle its own reconfiguration, and not by the external modules. One service may want to execute stop/start while another ony may want to just apply part of the reconfiguration. And the fact to reconfigure a service is itself an information, eg, some services may perform some actions EVENT if the configuration stays exactly the same!

Let each service be fully responsible for it's own start/stop/restart/... behaviors (single responsibility principle).

Last edited 4 years ago by stibbons (previous) (diff)

comment:11 Changed 4 years ago by dustin

I think that's the idea here -- schedulers should get their reconfigService methods called on reconfig.

comment:12 Changed 4 years ago by dustin

  • Version 0.8.5 deleted

comment:13 Changed 3 years ago by dustin

  • Milestone changed from 0.9.0 to 0.9.+
Note: See TracTickets for help on using tickets.