Joe Attardi wrote: > Hi all, > > I've been thinking all day about what exactly this package > management/update area of sipXconfig should do, and come up with a list > of incremental tasks/steps to reach these goals. >
[...] > > (1) Create a Python script that uses the Yum API to access the different > package management commands, and corresponding Java classes to handle > the output. This way we don't have to rely on the output of the yum CLI > tool itself. I would think we need 3 primitives: - check if there is an "update" - download - install/upgrade Not sure if you can separate download and install but it would be nice. > > (2) Create a "Software Updates" section in the UI and as a first step, > show information about the packages installed. Ideally we should > separate sipX packages and OS packages in the UI - two separate > lists/tables. Do we really need UI to show all package versions? There is already a version of sipXecs that we can show - pretty much the same info that in the footer. I do not think we need to show all packages installed on the system and their versions. > > (3) Add functionality to enable or disable repositories from a > predefined set. We can include the unstable repository, but it will > carry a stern warning that you shouldn't use it. (This is how Trixbox > does it). Why? I did not see any use case in which we need to disable and enable any repository. > > (4) Add the ability to check for available updates to sipX packages > and/or OS packages, and have sipX periodically check for updates in the > background. When updates are available, send an email notification and > show a notification in the sipXconfig UI that updates are available. Less important than upgrade on demand. And can be done independently. Checking on demand is the only necessary thing. > > (5) Add the ability to update the sipX packages and/or OS packages on > demand. We agreed to support "upgrade": there is no choice to be made by administrator here. She upgrades to next version or not. Everything else upgrades with it. But this needs to be split even more: - running the script - waiting page - confirmation when first login after succesful upgrade > > (6) Add the ability to schedule the update process at a later time. > > (7) The big finish: Support for updating all the servers in a > distributed system. That's probably more important than scheduling and automatic checking for updates. > > This is a big list, but please feel free to comment. The more feedback I > get, the better. > You might be missing some tasks related to finding and installing a next major release repo files. Second story from my initial e-mail. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
