On Fri, 2009-01-23 at 12:59 -0500, Raymond Dans wrote: > In order to test changes XECS-2072, I've had to do upgrades from 3.10.x > to 3.11.9. Unfortunately the upgrade to 3.11.9 (r14537) did not go > smoothly. I've noticed a number of issues and couldn't find > corresponding Jira's for them. In order to ensure that these problems > don't slip through the cracks, I'd like to know if they are valid issues > (since I've never really done upgrades before) and secondly whether or > not the issue has been addressed in some Jira already: > > 1. SipXecs 3.11.9 includes a number of new RPMs that were not in 3.10.x. > Simply doing a "yum update" will not update/install all rpms. In order > to upgrade the system, I had to do a "yum install sipxecs" (sipxecs is > one of the new rpms and it essentially has dependencies on all other > sipx rpms), followed by a "yum update". Is this going to be the > required upgrade procedure?
That sounds like the right procedure (the commercial version will use a different top level rpm name). > 2. The sipxconfig rpm and sipxconfig-mrtg rpm contain a duplicate file > (sipxconfig.properties.in). Is this intentional? To me, the file > should be only in the sipxconfig rpm as the sipxconfig-mrtg rpm is > dependent on sipxconfig. No... that's a bug. You can't have two rpms that contain the same file. > 3. Once everything was upgraded and I tried restarting sipxpbx, only > sipxsupervisor and httpd were started. This was because the sipxconfig > config version (new in 3.11.x) was not set and the process was not > marked to be started. Both of these actions are currently done in the > sipx-setup (or dependent) script which of course is not run in an > upgrade scenario. Of course any solution to this should take into > account whether or not you're on the Master or a Slave. Yes, we're going to have to do something about that for upgrades... please file an issue on that. > 4. After getting sipxconfig started (by using sipxproc to set the config > version and startup status), I was able to log into the Admin. > Unfortunately no other services were started. When checking the > Services area, I noticed that the IP address of the server was not set > and none of the "Roles" were selected. I'm not sure how this could be > handled but it looks like the upgrade process will have to somehow > examine what services were active before and somehow map that to the new > "Roles" mechanism. Again, the previous service states need to be imported during the upgrade somehow. A job for sipXconfig, I think... _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
