Scott Lawrence wrote: > On Tue, 2008-09-09 at 00:19 -0400, Damian Krzeminski wrote: >> Kevin Thorley wrote: >>> On Mon, 2008-09-08 at 20:46 +0000, Scott Lawrence wrote: >>> [...] >>>> Other than a general objection to polling, I guess not. What frequency >>>> were you thinking of using? >>>> >>> I have a general objection to polling as well, but this seems to be the >>> easiest way to squeeze this in to sipXconfig during this sprint. Damian >>> had mentioned a 30 second polling interval. I think we could safely go >>> up to 2 minutes and still maintain a reasonable amount of "liveness" in >>> the system. We could also make this a configurable param (either >>> through sipXconfig or a config file) if it were to cause problems in >>> certain network environments. >>> >>> Kevin >>> >>> >> sipXconfig is only going to poll when admin adds a new server which is not >> configured yet, right? >> It's not going to poll all the servers, all the time (at least not for that >> reason). >> >> And if that's the case we can get down to about 10 seconds: the goal is to >> get the new server noticed and configure it as soon as it starts. >> >> How about the Raymond's question though: how does sipXconfig is going to >> contact supervisor for the first time? >> >> Looks like the initial exchange was to be done through HTTP PUT of the >> gzipped file. See: >> >> http://track.sipfoundry.org/secure/attachment/15317/ClusterManagement.html#config.if >> >> Which would suggest that the polling could be implemented as HTTP GET on >> the same URL. Bad idea? > > We need to review the initial setup scenarios in more detail, but this > is _not_ just to support that. > > Suppose that any configuration change is made, and the push of that > change to the distributed system fails because that system is down? > When the distributed system comes back, the checkin provides the > stimulus to tell sipXconfig that it can now successfully send the > update. > > On the other hand, that doesn't help if the problem was a network > problem but both systems were up, so I guess you have to poll for that > one anyway. > >
Yes - one of the sides has to actively poll if we want to make sure that config changes are properly replicated. I guess what I was trying to propose is the phase based approach to implement the current spec. The initial phase - something that we would do in sipXconfig as a part of this sprint - would be just adding a "Send Profile" button to server page. That would be in line with what we are doing for phones, gateways and other device and if I do not miss anything would allow admin to configure remote system from sipXconfig UI. Then we can add servers polling - more frequent for newly added servers, less frequent for the ones that have been configured. That would allow us to push And even later we can implement check-in interface: that would let new and restarted servers to register with sipXconfig and allow it to react very quickly when server is up. I am hoping this might help us to concentrate on the most important problem at hand: how to initially configure remote server and will leave the open door for the improvements. Damian _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
