Scott Lawrence wrote: > On Mon, 2009-01-26 at 15:32 -0500, Damian Krzeminski wrote: >> Ideally of course we would somehow capture the list of services that >> are >> running before the upgrade, upgrade the system, translate the services >> into >> roles and enable the specific roles. Any ideas how to do that? >> >> If that's not practical to implement - what's the next best thing? > > We could parse the old process definition files if they exist. > > I'd say the safest way to do that would be to parse the old definitions, > find the enabled processes, and write the names of those processes into > a file 'owned' by sipxsupervisor. The sipXconfig could then GET that > file from each system in the cluster (which it can get from topology.xml > on the master) and use the data to reconstruct the service/system > relationships. > >
That might work: the file will have to be made available by supervisor so that sipXconfig can retrieve it during its "first-run" phase and initialize the services/roles accordingly. So this is pretty much division of the work: - sipXsupervisor: parse-old-services script - added to sipx-supervisor, called during RPM installation (new RPMs are installed before old are removed, the script needs to be called from the RPM to work) - sipXconfig: retrieves old-services script through XML/RPC (needs to do it for all the location/servers migrated from topology.xml) - sipXconfig: enables roles the contain old services Makes sense? D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
