> > Scott Lawrence wrote: > > > Regardless of the specifics of any problems with the scripts, I don't > > > see why sipXconfig should be doing one thing to upgrade the local system > > > and something else to upgrade a remote system. Why shouldn't it just do > > > the same for both, always operating through sipXsupervisor? This is the > > > way we do most things...
> On Fri, 2008-12-05 at 15:13 -0500, Joe Attardi wrote: > > My only real objection to this - and feel free to correct me if I'm > > wrong, as this is not my area of expertise by any means - is that by > > running it directly on the local system, we can read the output as it > > happens to provide a notification of the progress of the upgrade process. > > > > For example while downloading, each line of output is prefaced by a > > progress indicator such as.. > > > > [4/125] Downloading somepackage.rpm... > > [5/125] Downloading anotherpackage.rpm... > > ... > > [124/125] Verifying: somepackage.rpm... > > [125/125] Verifying: anotherpackage.rpm > > > > Done! On Fri, 2008-12-05 at 16:41 -0500, Kevin Thorley wrote: > I'm sure we could find a way to do this remotely as well. Perhaps every > 30 seconds sipXconfig could invoke the remote script (via > sipxsupervisor) to read the output file and return some info (percentage > complete, estimated time remaining, etc). Polling is one answer. An even better one would be to do the monitoring a the system doing the upgrade and have the manager (sipXconfig) provide an interface (HTTP POST or XML-RPC) to which progress indications are sent. I don't insist by any means that this happen for 4.0. I do think that our presumption should always be that every action be taken identically for remote and local targets and that we should design with that assumption in mind from the beginning. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
