On Thu, 2008-10-30 at 09:26 -0400, Damian Krzeminski wrote: > Huijun Yang wrote: > > Hello, > > > > From previous discussion, it was agreed to add domain aliases into > > domain-config, and also include _all_ the IP addresses of _all_ hosts. > > > > While implementing it (_http://track.sipfoundry.org/browse/XCF-2993_), I > > realized one problem we have to address first. With this approach, when > > adding a new server, it will trigger an update on domain-config, and we > > need to restart services that are using domain-config (maybe should be > > all services) to reflect the chagnes, but that will lead to unwanted > > experience, for example, quoted from Damian from an offline discussion > > "I agree with you it's the right thing to restart services, but... it's > > really a terrible experience (I am adding a remote server why do I need > > to restart all the services)"? > > > > If we do not restart services, services will be using data that has been > > out of date, which will devalue the point to include _all_ the IP > > addresses of _all_ hosts. > > > > What's the advantage of having all servers know all other server addresses? > If there is a real advantage, then we just have to restart all the servers > when you add and remove server. > > Also: does it really have to be in domain-config. If anything is changed in > domain config we need to restart all the services (because anybody can use > domain-config). If this information is needed only by one or two services > we are better off putting it there: restarting proxy and registrar is way > less disruptive than restarting everything.
We've had a seemingly endless stream of "I want to do xyz with a domain alias" issues; I'd rather just make the knowledge global and be done with it. The user should be notified that a restart is needed when a system is added to the cluster, but as Kevin suggested it need not be immediate, and we should probably think about making it a "rolling" restart (Call routers one at a time first, then other applications...). _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
