On Sat, Feb 4, 2012 at 10:39 PM, Douglas Hubler <[email protected]> wrote: > On Sat, Feb 4, 2012 at 3:23 PM, Tony Graziano > <[email protected]> wrote: >> If there are several different changes, should that table allow the >> admin to combine them for one scheduled change? > > They changes would combine automatically, it's how > >> On Sat, Feb 4, 2012 at 3:18 PM, Martin Steinmann <[email protected]> wrote: >>> If we have scheduled restarts of components, we will also need a table where >>> we can see what actions are queued and at what time. What if several >>> changes are made that trigger such action? > > Good point! If admin schedules a CDR change and a Proxy then comes in, > it would be too hard to implement have manage multiple scheduled > pending config changes. > > The schedule part i think i too fancy to get right the first time. > Strike the schedule, and admin just gets a UI to proceed or cancel and > leaving pending config changes. > >> Should the operator be able to >>> roll back or cancel a change before it is activated? > > It would be very useful to do this, but we don't have that capability > and it would be difficult i think because postgres data has already > been committed. Not impossible for future revs i think. > >> Should the operator be >>> informed after the action was taken about its status? > > yes, job status table as before.
On a side note and since we already migrated to MongoDB - maybe it would make sense for 4.8 or so to entirely get rid of services restart (in current code I see no reason for restarting java based processes for example) -- George ---------- Come meet us at CoLab @ CSU in March (5th & 6th) http://www.sipfoundry.org/sipx-colab http://wiki.sipfoundry.org/display/sipXecs/2012+sipX-CoLab+Hackfest _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
