+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
