Kevin wrote: > There is an issue in jira > (http://track.sipfoundry.org/browse/XCF-2615) > that requests that we add an API call to sipXconfig to allow > sipXsupervisor to let sipXconfig know that a new distributed > system has come online and is ready to receive configuration. > After discussing this in the sprint planning meeting today, > we decided it would be easier to have sipXconfig poll the > sipXsupervisor on the distributed system (assuming that the > distributed system has already been added in the sipXconfig > Server screen, which was agreed upon in the cluster config > meeting a couple months ago). Once sipXconfig is able to > contact the sipXsupervisor on the distributed system, it will > push the configuration. Does anyone object to this approach? > > Additionally, we plan to add (as a separate issue) a button > to the Servers screen that will allow an administrator to > replicate all configuration files to a specific distributed > system. This will handle the case (among others) where a > distributed system is re-installed and needs to have its > config replicated after the initial replication > Given that I have the Jira issue (XECS-1485) that was to call the new checkin interface from the slave, I have no objections :) I can't see any problems with this approach as long as the polling isn't too frequent. I would like to know, however, how you are going to "contact" the sipXsupervisor on the slave?
Raymond _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
