FTS Deployment Tests

The purpose of the deployment tests is

• to see if the packages are properly built
• configuration (Yaim) scripts cover all expected deployment models
• installation from scratch works
• upgrade paths are working

Test Environment

The DMTestBed's dynamic test machines shall be used, because they provide a clean environment in the quickest possible way.

After a successful release candidate build using ETICS one can upload the packages to the release candidate repository by using the e-to-apt script:

SLC4

etics-workspace-setup
etics-get-project org.glite
etics-checkout --continueonerror --ignorelocking --project-config glite_branch_3_1_0 -c glite-data_branch_3_1_0_dev org.glite.data
etics-build --continueonerror org.glite.data
e-to-apt

SL5

etics-workspace-setup
etics-get-project org.glite
cat <etics.properties >>EOF
org.glite.service-discovery.build-common-cpp.DEFAULT=glite-service-discovery-build-common-cpp_R_0_2_0_1
org.glite.service-discovery.api-c.DEFAULT=glite-service-discovery-api-c_R_2_2_2_2
org.glite.service-discovery.file-c.DEFAULT=glite-service-discovery-file-c_R_2_1_2_2
org.glite.service-discovery.bdii-c.DEFAULT=glite-service-discovery-bdii-c_R_2_2_2_3
org.glite.service-discovery.cli.DEFAULT=glite-service-discovery-cli_R_2_2_1_2
EOF
etics-checkout --continueonerror --ignorelocking --project-config glite_branch_3_2_0 -c glite-data_branch_3_1_0_dev org.glite.data
etics-build --continueonerror org.glite.data
e-to-apt

For the dependencies and metapackages one shall use the production gLite repository.

If the provided dependencies or metapackages are not recent enough, then these extra packages could be also uploaded to the release candidate repository.

Test Cases

Clean Installations

As it is described in LCG.FTS22 one shall be able to install FTS on a clean machine:

• FTS, FTA, FTM on a single SLC4/i386 node: not really used in practice, but the library locations are different, so at least one 32 bit installation shall be tested.
• FTS, FTA, FTM on a single SLC4/x86_64 node
• FTS, FTA, FTM on a single SL4/x86_64 node: the difference is that we shall not use the 'cern-only' Java and Oracle Instantclient packages.
• FTS, FTA, FTM on a single SLC5/x86_64 node
• FTS on two nodes, one FTA with VO agents, another FTA with channel agents and a separate FTM node: this would be the typical deployment model, however this test could be simply covered by the /Pilot/ installation.

Upgrade Paths

From the previous release of FTS (2.1) we should exercise and document the upgrade steps to the most recent release (2.2):

• Upgrading FTS on the same node, using the same Yaim site.def file: we have deprecated a number of attributes, which shouldbe deleted, otherwise the upgrade should show warnings. The schema has also changed, so its upgrade will be also tested.
• Installing FTA on a clean machine and "moving" channels over from the existing installation: what is the simplest way to "clone" configurations and how to remove everything cleanly from the old box?
• The same as above, but the old machine runs on SLC4, while the new one on SLC5.
• Installing a new FTS 2.2 and FTA nodes with a new database on SLC5 and cloning the SLC4 FTS 2.1 configuration in this one: this will be the typical pre-production testing model at most sites. The trick here is that not all channel parameters are coming from the Yaim site.def file, thus we shall have clean instructions on how to copy the necessary information from the t_channel table into the new databse.

-- Main.AkosFrohner - 15 Mar 2009