Moving 'data' from RTC and RQM v 2.x to new machines v 3.x

Hi,

you can't just copy data around. Upgrading to 3.0.x is a process that is described in the product help, for instance the interactive upgrade guide http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/roadmap_clm_upgrade.html. Another source for information is this article: https://jazz.net/library/article/698. Basically you need to run the upgrade scripts to merge your teamserver properties data and some other information from the applications into the Jazz Team Server.

In the upgrade process you can also distribute JTS and attach the applications to it. You still can't change the context roots. Please follow the process described in the interactive upgrade guide. I would also suggest to test the upgrade some times and document the steps, to be able to perform the final upgrade without issues.

Hi,

you can't just copy data around. Upgrading to 3.0.x is a process that is described in the product help, for instance the interactive upgrade guide http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/roadmap_clm_upgrade.html. Another source for information is this article: https://jazz.net/library/article/698. Basically you need to run the upgrade scripts to merge your teamserver properties data and some other information from the applications into the Jazz Team Server.

In the upgrade process you can also distribute JTS and attach the applications to it. You still can't change the context roots. Please follow the process described in the interactive upgrade guide. I would also suggest to test the upgrade some times and document the steps, to be able to perform the final upgrade without issues.

I see what you're saying does not work, because I just tried using repotools to import an old backup, and now everything seems to be broken.

I have been messing around in the documentation for so long now. If I should use the interactive upgrade guide, maybe you can tell me which of the two options: "I want to install the new Jazz Team Server on the same machine as my existing application" or "I want to begin to distribute my applications on multiple machines" I should choose? I really want to do neither. I want to upgrade RTC 2.x to a new machine, so it is not the same machine, but also I dont want to distribute my installation.

As this is something which is pretty crucial to the rest of the update process, I am completely at a blank what to do here. I have tried selecting to install on the same machine and follow the steps to my best ability, with no luck, of course.

Also, is there any way I can copy the whole version 2.x installation to the new machine so I can try updating the installation seperately from the fallback installation on the old machine?

I am looking at this staging article http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/index.jsp?topic=%2Fcom.ibm.jazz.install.doc%2Ftopics%2Ft_prepare_staging_env.html, but it does not seem clear if I just copy over the whole /JazzTeamServer directory and backup the databases to the staging machine?

Hi Martin,

I would wish it was so easy.... You can go into the article I mentioned and also have a look at http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/c_planning_upgrade.html for considerations.

I can only give some hints here.

You can upgrade to different topologies. Fully distributed: JTS, RTC, RQM have their own URL, typically, but not necessarily they would have their own server too. You can upgrade RTC to be co-located with JTS, both run on the same server. Potentially you could give both a different URL using yirtual host names. You can hook RQM to the same JTS, but please be aware that the URI can not change.

The choice would be "I want to install the new Jazz Team Server on the same machine as my existing application" to co-locate JTS and RTC on a server. Please be aware that this is - for the time being - a final decision due to that the URI can not be changed. Also there are obviously scalability and performance trade-offs running all on the same machine. If you run into resource constraints on one machine you cant split the applications if they use the same host name in the URI.

You can, as far as I know not upgrade RTC and RQM into the same application server. The reason for that is they share the context root /jazz which prevents for them being installed and deployed on the same application server. You might be able to install two application servers on the same machine, one hosting JTS/RTC and one RRC. The issue I could see with that is, in case you have used the same port numbers for RTC and RQM e.g. 9443, since that belongs to the URI both would have to run on port 9447 which is impossible except, maybe, some advanced tricks such as virtual hosts. Several application servers would use more machine resources too, which would be a potential issue should your usage grow in the future.

I'd suggest to make a drawing of your current deployment and how you could fit that with a new JTS. there are also advanced techniques such as proxy or virtual host names, DNS aliases that can help.

Unfortunately there is no one size fits all here and it is really important to go through the considerations. We create an upgrade workshop that you could find in the library that could also give you a better understanding of the upgrade process.

That depends a bit on what infrastructure you use. with Apache/Derby it is more or less copy over. Apache and another DB too, except you need to make sure to fix the DB connection strings too. There is an article in the library about backing up (for 3.0) that is partially relevant for 2.0 too, except there is no JTS. You can also do a new install, restore the configuration files in the test env to fit the production machine, restore the DB or do a repotools import. Please keep in mind that RTC/RQM use several text files for indexing. You can either copy them into the same absolute/relative location or recreate all the index files.

Please be aware that the test environment needs to be isolated (network) to prevent it to interact with the existing environment.

Hi Martin,

I would wish it was so easy.... You can go into the article I mentioned and also have a look at http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0m1/topic/com.ibm.jazz.install.doc/topics/c_planning_upgrade.html for considerations.

I can only give some hints here.

You can upgrade to different topologies. Fully distributed: JTS, RTC, RQM have their own URL, typically, but not necessarily they would have their own server too. You can upgrade RTC to be co-located with JTS, both run on the same server. Potentially you could give both a different URL using yirtual host names. You can hook RQM to the same JTS, but please be aware that the URI can not change.

The choice would be "I want to install the new Jazz Team Server on the same machine as my existing application" to co-locate JTS and RTC on a server. Please be aware that this is - for the time being - a final decision due to that the URI can not be changed. Also there are obviously scalability and performance trade-offs running all on the same machine. If you run into resource constraints on one machine you cant split the applications if they use the same host name in the URI.

You can, as far as I know not upgrade RTC and RQM into the same application server. The reason for that is they share the context root /jazz which prevents for them being installed and deployed on the same application server. You might be able to install two application servers on the same machine, one hosting JTS/RTC and one RRC. The issue I could see with that is, in case you have used the same port numbers for RTC and RQM e.g. 9443, since that belongs to the URI both would have to run on port 9447 which is impossible except, maybe, some advanced tricks such as virtual hosts. Several application servers would use more machine resources too, which would be a potential issue should your usage grow in the future.

I'd suggest to make a drawing of your current deployment and how you could fit that with a new JTS. there are also advanced techniques such as proxy or virtual host names, DNS aliases that can help.

Unfortunately there is no one size fits all here and it is really important to go through the considerations. We create an upgrade workshop that you could find in the library that could also give you a better understanding of the upgrade process.

Hi Ralph,
I am not sure but there seems to be some confusion. I had tried to make it clear how the topology was to be. I have as it is now two machines. One of them holds its own RTC and JTS installations, its own databases and everything is encapsulated. The other machine is just the same, except it is RQM instead of RTC. The two machines do not communicate in any way.

All I want is to achieve the same setup, except with the new versions, and on two new machines (but of course the two machines will have the same hosts AFTER the update to preserve the URIs).

I have been trying to install the new version to the new machines in hope of then moving the data from the old installations to the new ones... with no luck :(

Should I now try to copy the whole 2.x installation of RTC to the new machine, and then try to follow the update procedure on the new machine? Maybe that is a better option.

You said you had installed RTC and RQM 2.x on the machines, so there is no JTS yet. But I see the other info now. By musing about what you did to the hosts, I have missed the important details....8-)

You can either upgrade to completely separate topologies RTC+JTS(RTC) and RQM+JTS(RQM) or you can upgrade to a topology with shared JTS. RTC, RQM, JTS where the JTS is on whatever machine you want, included a 3rd one. The First scenario 2 machines with each an application RTC or RQM and a dedicated JTS for each is "I want to install the new Jazz Team Server on the same machine as my existing application" for both. If you share the JTS you decide only once and the choose you have a JTS already in the subsequent upgrades. The upgrade workshop shows that with WAS.

The completely separate option will require Insight in case you want to do reporting across both RTC and RQM. The built in capabilities and RRDI don't handle multiple JTS. Also multiple JTS will require separate license and user management. In a typical environment a shared JTS is preferred. However the choice is yours. It can not be changed later unfortunately.

You could also decide to go for a shared JTS but fake a distributed topology with a 3rd host by having a host name alias for one of the machines and using the second host name in the JTS URI.

You said you had installed RTC and RQM 2.x on the machines, so there is no JTS yet. But I see the other info now. By musing about what you did to the hosts, I have missed the important details....8-)

You can either upgrade to completely separate topologies RTC+JTS(RTC) and RQM+JTS(RQM) or you can upgrade to a topology with shared JTS. RTC, RQM, JTS where the JTS is on whatever machine you want, included a 3rd one. The First scenario 2 machines with each an application RTC or RQM and a dedicated JTS for each is "I want to install the new Jazz Team Server on the same machine as my existing application" for both. If you share the JTS you decide only once and the choose you have a JTS already in the subsequent upgrades. The upgrade workshop shows that with WAS.

The completely separate option will require Insight in case you want to do reporting across both RTC and RQM. The built in capabilities and RRDI don't handle multiple JTS. Also multiple JTS will require separate license and user management. In a typical environment a shared JTS is preferred. However the choice is yours. It can not be changed later unfortunately.

You could also decide to go for a shared JTS but fake a distributed topology with a 3rd host by having a host name alias for one of the machines and using the second host name in the JTS URI.

Hi Ralph,
That sounds good! I think now we're finally on track to what I want to accomplish. Preferably, I would like the RTC server and the QM server to share a single JTS server (I have a third server I can use for this). However, I tried already to set this up, with RTC+JTS on one server and QM on another server, but when I tried to register QM with the JTS there were conflicts because they both use the /jazz context root, it seems.

But again, now that you know what I want to accomplish, maybe you can say what is the way to go? Because my managers will not allow me to mess around with the current installations, they want those as a fallback installation, and are using them as I am trying to figure this out.

So what is the better option for me? To copy the current installations of RTC to machine 1 and copy RQM to machine 2, and then upgrading them seperately (possibly registering them to a shared JTS on machine 3)? Or is a fresh install on machine 1, 2 and 3 possible, and then afterwards migrate the data?

Please read the upgrade workshop. Really. It will help, even if it is for WAS. Also play with the interactive upgrade guide.

You don't necessarily have to recreate a running 2.x install in the test environment. For the upgrade you need:

A copy of the RTC/RQM 2.x files on the test machines. Them being able to communicate but be isolated from your running environment.
A backup of the RTC DB. A repotools export of RQM.

You could however also try to setup a complete environment.

The jazz context root is no issue when registering RQM/RTC to a shared JTS, if they are deployed in different application servers.

Please read the upgrade workshop. Really. It will help, even if it is for WAS. Also play with the interactive upgrade guide.

You don't necessarily have to recreate a running 2.x install in the test environment. For the upgrade you need:

A copy of the RTC/RQM 2.x files on the test machines. Them being able to communicate but be isolated from your running environment.
A backup of the RTC DB. A repotools export of RQM.

You could however also try to setup a complete environment.

The jazz context root is no issue when registering RQM/RTC to a shared JTS, if they are deployed in different application servers.

Hi Ralph,
I will try having a look at the upgrade guide. I dont know what you mean by "WAS", but I assume it means it is for a Windows Server or something like that. Anyway, I will have a look at the written material in there.

Could the following be a good way to progress?

• Install JTS 3.1 on machine 3 (this will be used as shared JTS server for CCM and QM)
  
• Copy the IBM/JazzTeamServer/ directory for the two installations (RTC copied to machine 1, and RQM copied to machine 2)
  
• Copy over backed up databases from the two version 2.x installations
  
• Restore those databases on the new machines
  
• Follow the Interactive update guide, first for RTC 2.x -> 3.x, and then for RQM 2.x -> 3.x. Here, I will select (for example for RTC):
  
  • Product: "Rational Team Concert"
    
  • Need JTS?: "I have already installed and configured the Jazz Team Server version 3.0.1 application"
    
  • OS: Linux
    
  • Server: Apache Tomcat
    
  • Database server: IBM DB2
    
  • Topology: "I distribute my applications on multiple machines"
    
  • Reporting: "I do not use Rational Insight or Rational Common Reporting"
    
  • Use LDAP

Does this strategy sound OK to you?