Joe I don't think we should ever show the admin a list of packages either sipXecs packages or OS packages. On the sipXecs side the UI should just state the currently running version and the version that can be upgraded to.
The default repositories should be hardwired. We could consider in an advanced section to allow the admin to specify .repo files to be loaded from a URL for both sipXecs and OS repositories. --martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attardi, Joseph (BL60:9D30) Sent: Friday, October 17, 2008 2:32 PM To: [EMAIL PROTECTED] Subject: [sipX-dev] Tasks for sipX system updates 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. I have spent some time looking at the package upgrade interface in Trixbox (Asterisk based), and it is pretty nice. See a screenshot here: http://blog.tmcnet.com/blog/tom-keating/images/trixbox-20-web-interface- large.jpg While I don't like everything about the UI, I do think that we need to take its capabilities into consideration when coming up with requirements for sipX's own package upgrade interface. So, after some thought, here is the list of tasks I have come up with. I have tried to list them in such an order that each task builds on the previous ones. Also, at each step I will need to make accommodations for both of the use cases Damian spelled out previously - minor updates, and major upgrades. I don't think we should, at this point, worry about major OS upgrades. Our latest supported Fedora version is Fedora 8, and Fedora 10 will be out soon - we are lagging behind, and don't really want to have our users upgrading to an unsupported distro :) (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. (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. (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). (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. (5) Add the ability to update the sipX packages and/or OS packages on demand. (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. This is a big list, but please feel free to comment. The more feedback I get, the better. _______________________________________________ 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
