I feel we've reached a time where we can migrate users over to the new system. I've worked out how to migrate the CQ database, build issues for both the old (salira) and new (salira2) vobs, multisiting is working, by and large scripts work as well as CQD. The following is a plan for migrating Salira to the new server. Please let me know your comments and concerns.
Time Spent: 2 hours
1.0 Migrating Clearquest
This migration is a little more critical because not only does the database need to be remigrated since bugs have probably been added since my test migration but clients must also update to the latest version of Clearquest in order to access the new database. Also, CQD (or rather CQD clients) need to ask the new server for information. Luckily the later involves a simply change to a library however timing remains important. This has to be done in one swoop.
The following needs to take place:
- Shutdown access to the database on sons-clearcase
- Backup the database
- Use installutil to copy the user db to the new server.
- Export and import user accounts (since you've made changes)
- Convert the database to SQL Anywhere 8.0 format
- Test new database
- Switch cqc.pm library to default to new server
- Have client upgrade to the new Clearquest
I suspect that the database conversion will take at most 4 hours so doing this on say Saturday or Sunday might be a good idea. As for desktop installations the users should be able to simply type "upgrade clearquest" in a Cygwin window. It will prompt the user to proceed then it will uninstall the old Clearquest, install the new Clearquest and reboot the users desktop. The user will then need to import a Clearquest connection profile and they should be set.
Bear in mind that is anything goes wrong the users should be able to use the CQWeb interface by pointing to http://sons-sc-cc/cqweb/login. China users will need to be made aware of the new server location in the URL but should otherwise be unaffected as I doubt that China users use the Clearquest client directly (way too slow!).
2.0 Migrating Clearcase
In general users need to stop using views that are sons-clearcase oriented. By that I mean they need to start checking in their work and generally getting their views to the state where they can remove them. Then they need to switch-<server> to sons-sc-cc and create new views there. As we are currently multisiting between sons-clearcase and sons-sc-cc they can migrate at their leisure however bear in mind that sons-clearcase should be going away. See also Mastership Issues below.
Users don't necessarily need to upgrade their Clearcase software as the old software will work with the new server, however you should urge them to do so. Again I plan on updating the upgrade command to likewise allow desktop users to simply type "upgrade clearcase".
One thing that users should do is change the symlink for /etc/site_parms from /view/official/Tools/adm/etc/site_parms.US to /view/official/Tools/adm/etc/site_parms.SC. Most of my scripts rely on this site_parms file to set environment variables to describe particulars about the site. This can be done with the following:
$ rm /etc/site_parms $ ln -s /view/official/Tools/adm/etc/site_arms.SC /etc/site_parms
3.0 Decommissioning sons-clearcase
Sons-clearcase has served you many years as the hub of both Clearcase/Clearquest services as well as a build machine. It has performed many duties and has done them well. Decommissioning such a server so near and dear to Salira's heart will take some doing, some finesse. The overriding concern is to untangle sons-clearcase from day to day operations and assign those duties over to sons-sc-cc in a proper manner before decommissioning sons-clearcase. Than have a nice going away party!
As users migrate to using the new server and once all elements are checked in and views are no longer needed they should be removed. We need to get to a place where all Clearcase activity on sons-clearcase is stopped, checked in and removed.
There are some ancillary functions that sons-clearcase is still performing that you may be unaware of such as licensing. These too will need to be transfered to the new server.
Finally sons-clearcase can be powered down and if there are any things we've missed it could be easily powered back up if need be.
3.1 Lock issues
One thing that is not multisited is locks on label/branch/etc types. Salira relies on these logs. I will need to write a script to evaluate the locks in the vobs on sons-clearcase and to issue the same locks on sons-sc-cc. I will work on this this week.
3.2 Mastership Issues
With multisited vobs comes issues of mastership. As you know a branch can only be mastered by one replica. The current vobs' main branch is mastered on sons-clearcase as are branches such as REL_1.0, etc. Mastership should be transfered to sons-sc-cc before sons-clearcase gets decommissioned.
There is a command called chmaster that luckily has a -all option to change the mastership of all objects to the new server. But it wants to have everything checked in and nothing locked.
3.3 Replica removal
With the vobs replicated to sons-sc-cc and all Clearcase views removed and mastership moved to sons-sc-cc, the final act would be to remove the US replica of the vobs from the vob family. This way sons-sc-cc and sons-cc in China would no longer attempt to update the US replicate on sons-clearcase (The replica on sons-sc-cc is called the SantaClara replica and remains in the vob family hosted by sons-sc-cc).
4.0 License Issues
Sons-clearcase also served as a license server for both Clearcase and Clearquest. Salira will need to contact IBM/Rational in order to obtain new licenses for these as they are host based. This can be delayed however it will need to be done before sons-clearcase can be decommissioned.
5.0 Miscellaneous Issues
There are several scripts which use some magic to determine where to find Perl library code (here or in China). That magic hard codes sons-clearcase as the server here to use. That'll need to change to use sons-sc-cc before a complete shutdown of sons-clearcase is doable.