> -----Original Message----- > From: Lawrence, Scott (BL60:9D30) > Sent: Monday, September 15, 2008 1:49 PM > To: Beeton, Carolyn (CAR:9D60) > Cc: [EMAIL PROTECTED] > Subject: Re: [sipX-dev] process management restructure question > > > On Mon, 2008-09-15 at 11:08 -0400, Carolyn Beeton wrote: > > > > Is the existing RPC defined in ProcMgmtRpc still intended > to function > > as currently implemented, but sending requests on the the new > > sipXsupervisor/SipxProcess? (this would be > setUserRequestState[All] > > where state is one of USER_PROCESS_STOP, USER_PROCESS_START, or > > USER_PROCESS_RESTART) > > > > My assumption so far has been that we would try to minimize > what sipXconfig needs to change to be compatible with the new > sipXsupervisor process management, and translate the "old" > rpc commands into the new process state model events > internally. I had not gotten far enough to be sure this > would not cause problems, though. > > The old process model was that sipXconfig (or some other > xml-rpc caller, in theory) issued stop/start/restart > commands. The new one is really that start and stop become > changes to the desired state, and restart becomes, in effect, > "stop this now but don't change the desired state, so it will > start again right away". Whether or not we should change the > xml-rpc interface may be worth discussing, but my feeling has > been that we could probably avoid it. > > The one important differenc that I think we will want to > expose is that the new supervisor process model has a lot of > information about _why_ a process is not starting, and that > should be made available to sipXconfig somehow so that it can > either act on it or display it for the admin. > > >
The existing rpc has a "blockForStateChange" parameter. Am I correct to assume that this goes away, replaced by each process's knowledge of its dependencies, based on the process definition? (It's a bad idea for xml-rpc stuff to block anyway, as the underlying connections time out...) Another question: how do the processes get "enabled" in the first place? They are currently coming up "disabled". Are we expecting sipXconfig to send a start command (xmlrpc) for each process on system start up (reflecting the HA distribution of services)? Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
