+2, maybe just uncover the option to manually control it in an advanced link?
>>> On 2/5/2009 at 1:16 PM, in message <[email protected]>, Melcon Moraes <[email protected]> wrote: +1 to visual cues and big fat warnings. On Thu, Feb 5, 2009 at 1:41 PM, Damian Krzeminski <[email protected]> wrote: Damian Krzeminski wrote: > Scott Lawrence wrote: >> On Tue, 2009-02-03 at 07:25 -0500, Damian Krzeminski wrote: >>> Nikolay Kondratyev wrote: >>>> Just imho: >>>> >>>> Won't it be better to keep "activate" button in the UI? >>>> >>>> Because there is hi possibility that "auto-activation" will lead to >>>> numerous proxy/registrar restarts instead of just one…. >>>> >>>> I think, that auto activation of dialplan creates conditions for >>>> significant non necessary downtime… >>>> >>>> Again: this is just imho from the administrator perspective… >>>> >>>> Thanks and regards, >>>> >>>> Nikolay. >>>> >>> Both proxy and registrar restart quickly and their restart does not affect >>> calls that are already in progress. It would be better if they did not >>> require restart after dial plan changes. >> In principle, dial plan changes should not be too hard to make >> reloadable, and we now have most of the infrastructure in place that we >> would need to do so (sipXsupervisor knows when they are replicated, so >> it could signal the process in some way to reload the files). Not >> something for 4.0, but a good candidate for 4.2. > > Great. I'll open an issue. > >>> We really cannot live with manual activation for much longer. There are >>> just too many places that affect dial plan and I have seen on this list >>> many reports of problems that originated from dial plan not being activated. >> I think a simple warning on the screen that you have uncommitted changes >> would help that quite a lot. >> > > That does not work for changes that are result of end user action. Only > administrator can activate the profile manually... > >>> The activation strategy has a "quite time" interval that can be tweaked - >>> by default it waits 15 seconds of quiet time (no dial plan related changes) >>> before activating it. >>> >>> Let's give it a try: if it causes problems we can get it back to "on >>> demand" strategy. >> I share Nikolay's concern... restart is not completely harmless... on a >> busy system (especially one without HA) it could be disruptive. > > That's troubling. I was under impression we talked about switching to > automatic activation for some time now. I guess I must have been having > this conversation in my head only. I apologize for not communicating it better. > Can we still try to test it or should I revert it now? > >> At the very least, I suspect that 'quiet time' should be much longer (at >> least a minute), and there should be a display on the page of what state >> it is in. > > Will increase it to 60 seconds if we decide this code can stay in. > >> Incidentally... on an HA system, does sipXconfig restart services on >> both systems at the same time? It would be less disruptive to restart >> services on each host on a rolling schedule so that redundant services >> won't be restarting at the same time. >> > > No - sipXconfig does not try to spread service restarts in any way yet. > D. > How about sipXconfig replicating the new dial plans but let's admin decide when to restart services. We could add visual cues to all the services that should be restarted and a big fat warning on top of every page that some services should be restarted... That would be consistent with many suggestions and existing issues around generating configs for devices (for example http://track.sipfoundry.org/browse/XCF-3170) D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
