> I agree with you. Changing the Domain Name is a very severe change however I don't think we want to change the model we currently are using. Meaning we need to be consistent with other changes. > Can't we just flag that all services should be restarted? And force a profile generation? In fact, currently, when a service is marked as "Restart required", its profiles have been replicated already, but just some of the configuration files that need the service to restart to pick up the changes will not take effect until the service is restarted. When domain is changed, I agree with you that we should mark all affected services as "Restart required" or it makes more sense that we just alert user to restart the whole system, as most services if not all will be affected by the domain change? cheers Huijun From: [email protected] [mailto:[email protected]] On Behalf Of Yang, Huijun (CAR:9D30) Sent: Monday, March 30, 2009 2:22 PM To: [email protected] Subject: [sipX-dev] Regenerate all profiles upon domain change? Hello, While investigating XCF-3554 <http://track.sipfoundry.org/browse/XCF-3554> :"Change domain name does not update voicemail.xml hence user fails to deposit voicemail", I found that the problem was not only applicable to voicemail, but also to any services that has dependence on domain name. Currently, when domain name is changed, only a few services' configurations, such as ivr service, proxy, registrar, etc. are replicated, but all other services that have dependence on domain name are not notified about the changes. Given domain name change is a critical change for the whole system, I think we should 1) push ALL service/locations profiles upon domain changes rather than trying to indentify and replicate only for SOME services 2) as device( phone and gateway) profiles also contain domain information, we should re-generate the device profiles as well, otherwise, the phone profiles will be left with invalid domain info, unless user regenerate them. Please let me know if you have any comments on the proposal. Thanks, Huijun
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
