TN0028: Workaround for the Jazz Team Server capacity problem (The “251st user” problem)

Last Updated: October 20, 2008
Authors: Don Weinand, Ryan Manwiller, and Darin Swanson Version: 1.0.1.1

Summary

In this Tech Tip we will provide step by step guidance of how to work around the Jazz Team Server limit of 250 licensed developers when working on multiple projects.

More Information

Let’s assume you run three project areas on one server. When you created the project areas it was not predictable that they might grow to their current level; you have reached the limit of 250 licensed developer on your server. You now need to add one additional developer to work on one of the projects. Floating licenses in 1.0.1 allow to mitigate the problem although it remains unsolved.

Proposed Solution

You have to move project areas and all of their associated artifacts from one Jazz Team Server to a new one. You can revoke the licenses for all users that are only working on the moved project. Rational Team Concert (RTC) is neither supporting such a move operation in 1.0 nor will it in 1.0.1. It however provides sufficiently powerful mechanisms that allow you a series of manual steps that in their outcome are close to a project area move. This is not a water-tight, nice solution but a pragmatic ‘dirty’ workaround to get users unblocked. Let’s assume ProjectArea1 needs to be moved from Server1 to the new Server2. Otherwise Server1 remains unchanged.

Expertise Prerequisites

This series of steps is intended for the expert RTC administrator or user. There are many steps, some of which cannot be undone. An advanced knowledge of RTC is required to understand some of the steps.

Using different RTC client sessions to view and manipulate the original and clone

In the steps below, you will be creating a clone of your database. Then, manipulating the original and clone. During these steps, it is required that you do not connect to both the original and clone from the same RTC session/workspace. To launch RTC with a different workspace, use the -data parameter. For example, when launching the first session, use -data original. When launching the second session, use -data clone.

This restriction applies only while executing the steps below. After successfully completing the steps, it is OK for users to connect to both the original and new servers from the same RTC session/workspace.

Integrated Steps

1. Stop all Jazz Build Engines that are communicating with Server1.
2. All developers with loaded repository workspaces that logically belong to ProjectArea1 on Server1 should either abandon their eclipse workspaces or disconnect them from their repository workspaces.
3. Take Server1 off-line.
4. Install a new Jazz Team Server: Server2.
   • If installing on the same machine be sure to also update the required port changes in Jazz as noted here: https://jazz.net/jazzdocs/index.jsp?topic=/com.ibm.team.install.doc/topics/t_s_server_installation_post_config.html
5. Use repotools to clone the current database of Server1 into Server2.
   • for example: /JazzTeamServer1/server/repotools.sh -clone toFile=/tmp/export.tar target.teamserver.properties=/JazzTeamServer2/server/teamserver.properties, where the target.teamserver.properties is configured to connect to a new database.
6. Use repotools to rebuild the text indices for Server2.
   • for example: /JazzTeamServer2/server/repotools.sh -rebuildTextIndices teamserver.properties=/JazzTeamServer2/server/teamserver.properties
7. Additional configuration files may need to be copied depending on the server configuration being used. For example, when using Tomcat without LDAP the tomcat-users.xml file needs to be copied from Server1 to Server2.
8. Start Server2 but don’t bring it generally online.
9. On Server2:
   1. Launch RTC and connect to ProjectArea1 on Server2.
   2. Open each build definition in ProjectArea1 to determine if it uses Jazz SCM.
      • You may get a dialog telling you the workspace has been deleted.
      • Switch to the Jazz Source Control tab and reconnect the build workspace for the build definition.
   3. Find each build engine associated with any team area not contained within ProjectArea1.
      • Determine if it supports build definitions that are associated with a team area within ProjectArea1.
        • If so…right click on it in the Team Artifacts view and open the build engine editor. Remove any build definitions that are not associated with a team area inside ProjectArea1. Change the team area that the engine is associated with to a team area inside of ProjectArea1.
        • If it only supports build definitions contained within ProjectArea1…right click on it in the Team Artifacts view and select delete.
   4. For each build definition associated with a team area not in ProjectArea1:
      • Double click on the build definition in the Team Artifacts view to find all build results for them.
      • In the Builds view select all the build results, right click and select delete.
      • In the Team Artifacts view, right click on the build definition and select delete.
   5. Log into the Jazz Admin Web UI
      • Click the Project Area Management tab.
      • Next to ProjectArea1 click the icon titled “Find Users not in the Project Area”.
      • Click the Archive All button to archive these users to prevent them from logging into the server and revoke any licenses.
   6. In RTC connect to all projects but ProjectArea1.
      • Open the project area editor.
      • Switch to the Process Configuration page.
      • Right click on the Project Configuration item in the tree and select “Revoke All Actions”. Enter a message indicating the project is still located on Server1.
      • Right click on the Team Configuration item in the tree and select “Revoke All Actions”. Enter a message indicating the project is still located on Server1.
      • Click the Save button.
   7. Open the Team Organization view.
      • Right click on each project but ProjectArea1 and select the Archive action.
10. Restart Server1 but don’t bring it generally online.
11. On Server1:
    1. Launch RTC and connect to ProjectArea1.
       • Find each build engine associated with any team area contained within ProjectArea1.
         • Determine if it exclusively supports build definitions that are associated with a team area within ProjectArea1.
           • If so…right click on it in the Team Artifacts view and select Delete to remove it from the repository.
           • If not…remove any build definitions that are contained within ProjectArea1 from the list of supported build definitions. Change the team area that the engine is associated with to a team area outside of ProjectArea1.
         • For each build definition associated with a team area in ProjectArea1:
           • Double click on the build definition in the Team Artifacts view to find all build results for them
           • In the Builds view select all the build results, right click and select to delete them
           • In the Team Artifacts view, right click on the build definition and select delete.
    2. Log into the Jazz Admin Web UI
       • Click the Project Area Management tab
       • Next to ProjectArea1 click the icon titled “Find Users in the Project Area”.
       • Click the Archive All button to archive these users to prevent them from logging into the server and revoke any licenses.
    3. In RTC open the project area editor for ProjectArea1
       • Switch to the Process Configuration Tab
       • Right click on the Project Configuration item in the tree and select “Revoke All Actions”. Enter a message indicating where the project has moved.
       • Right click on the Team Configuration item in the tree and select “Revoke All Actions”. Enter a message indicating where the project has moved.
       • Click the Save button.
    4. Open the Team Organization view.
       • Right click on ProjectArea1 and select the Archive action.
12. Bring Server1 back online for general use.
    • Restart all Jazz Build Engines communicating with Server1 that was supporting builds outside of ProjectArea1.
13. Bring Server2 back online for general use.
    • Start new instances of the Jazz Build Engine for the build engines that are associated with team areas in ProjectArea1 on Server2.
    • The developers of ProjectArea1 should recreate or reconnect their eclipse workspaces to their repository workspaces.

Special Notes

• All build results that are part of ProjectArea1 on Server2 will have two issues:
  • An error will display for the repository workspace on summary tab when the build result is open.
  • It will not be possible to re-run a build for a given build result.

CQ Connector and CC Connector Component Specific Steps

CQ Connector

• Project areas are associated with CQ databases by containing synchronization rules that reference the connection info for a CQ gateway process that serves the database.
• If work items for ProjectArea1 are being synchronized with CQ records, then synchronization must be transferred to Server2.
• If work items for any other project areas are being synchronized with CQ records, then synchronization must be disabled for them on Server2.
• Therefore, if synchronization with CQ is configured for any project area, follow these additional steps:
  1. Before shutting down Server1 to export the database, disable outgoing synchronization in the external repository connection for the CQ database.
  2. Shut down the CQ Connector Gateway process for the CQ database.
  3. To transfer synchronization of ProjectArea1 work items to Server2
     • Add the URL for Server2 to the CQ Connector Gateway configuration (if not there already), and if ProjectArea1 was the only project area being synchronized from Server1, remove the URL for Server1 from the configuration.
     • When Server1 is back online delete the synchronization rules from the now archived ProjectArea1.
  4. To disable synchronization of other project areas on Server2 that will be archived, delete the synchronization rules for those project areas on Server2, after it is online.
  5. Restart the CQ Connector Gateway.
  6. If ProjectArea1 was configured for synchronization, enable outgoing synchronization in the external repository connection for the CQ database on Server2 and verify that synchronization is working.

CC Connector

• SCM modifies the IDs of workspaces and streams as part of the migration. This results in invalid references remaining to workspaces and streams in our stream Proxy object. Therefore we require that the user delete all synchronized streams in a team area being migrated, and re-create them in the new repository after the migration.