On Fri, 2008-10-17 at 14:31 -0400, 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. > > 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.
Good, but I don't think that at this point we need to have per-package controls the way the trixbox example you showed does. We have not yet supported cafeteria-style installations: you get everything every time (in 4.0 you can decide what runs, but everything is assumed to be installed). Allowing cafeteria style puts a lot more pressure on us to get every dependency exactly right, and enormously increases the testing/support burden (X doesn't work if Y is not installed). > (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). I'm not really sure we need this yet either, for the same reasons. My feeling is that each major release gets its own repo, and changing that is independent from checking status within a repo (along the lines of what Damian suggested). > (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. Comments for the next three grouped below: > (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. (6) is lower priority than 5+7 (enough lower that I think we don't need it for 4.0), and while implementing 5 and 7 incrementally makes sense, we need 7 before we have a feature, since a large and growing percentage of installations are HA. > This is a big list, but please feel free to comment. The more feedback I > get, the better. Good job. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
