On Tue, 2009-01-13 at 10:25 -0500, Carolyn Beeton wrote: > I am wondering how far I should take the "special" process definition > file for sipxsupervisor > (http://track.sipfoundry.org/browse/XECS-2031). > > The first step is to define its own resources there (currently they > are farmed out on other unsuspecting processes). > > In this first step I am not blocking on the resources - if supervisor > doesn't start up sipXconfig then it would never unblock. So the > supervisor process is very special - it only creates resources, does > not track its own state - including blocking on configurationMismatch, > ResourceRequired, running configtest, etc., and does not allow > start/stop/restart of itself. > > The question is, should I take the next step of making sipxsupervisor > look more like a full blown SipxProcess, with all (or most of) the > state transitions that implies? > > For example, maybe high-level configtest should be run during start-up > of sipxsupervisor. It does not appear to run at all during normal > operation (only if you explicitly call sipxpbx configtest). [Or > should sipxpbx start/restart be running the configtest first?] I > could also - possibly - do stop/restart for the supervisor (i.e. the > entire sipxpbx). It would be a bit tricky, but I'll do it if it seems > the right thing to do.
The running of the configtest step was removed from the sipxpbx startup script in favor of the sipxsupervisor running it - I don't think we should change that. I think that the philosophy has to be that sipxsupervisor just always runs and does the best it can with what it finds. It shouldn't give up completely no matter what, so I'm not sure that a configtest for it really serves any purpose. I'd say that just doing the first step of getting resources properly defined so that they can be used by sipXconfig is probably all that we should do for now. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
