'Move to Certification' Check list

The following list must be used in combination with the Integration Procedure twiki that describes all the technical details involved in the release process. This twiki aims to list the necessary steps to move a patch into Ready for Certification helping to avoid mistakes and decrease human errors.

It's also important to check the How to fill a patch twiki to get familiar with the required syntax for each Savannah field.

Pre requirements

The following machines are needed in order to do a production release:

• glite 3.1, 32bit: SLC4/32bit repo machine with glite-release CVS module.
• glite 3.1, 64bit: SLC4/64bit repo machine with glite-release CVS module.
• glite 3.2, 64bit: SL5/64bit repo machine with glite-release CVS module.

Check List

Once a day query Savannah for patches into Ready for Integration. For each patch follow the steps below:

1. Check whether the patch affects SL4/32bit, SL4/64bit and SL5/64bit nodes. If this is the case, a patch for each architecture should be opened. Sometimes developers already submit two or three patches, otherwise clone the existing one and modify it for the missing architectures.

2. Check if any of the following packages are released in the patch and are affecting WN and UI in SL5/64bit, or WN in SL4/64bit:

CGSI_gSOAP_2.7-voms
CGSI_gSOAP_2.7
DPM-client
DPM-interfaces2
DPM-interfaces
GFAL-client
glite-security-voms-api-cpp
glite-security-voms-api-c
lcg-dm-common
lcg_util
LFC-client
LFC-interfaces2
LFC-interfaces
vdt_globus_essentials
libdcap
libdcap-devel
libdcap-tunnel-gsi

In this case, follow the steps described in this How to, to deal with group install patches. (UNTIL BUG:56188 IS FIXED)

3. Check the RPM names. All the rpms that the patch changes or introduces as new dependencies should be included here. Even the rpms that are provided in the Externals field! Make sure the syntax is correct: name-x.y.z-r.(os.)arch.rpm

At this point it's good to check whether there are rpms that already exist in the production (or preproduction) repository. If that's the case, those rpms should appear in the Metapackage changes. Otherwise it's useless information and they should be deleted from the list. If this is the case it's better to clarify with the developer why he has included them.

4. Check the Affected Metapackages list. There's a script that tells for a certain list of rpms, which metapackages have dependencies on them. Run this script and make sure the list is complete. The script can be found in the Savannah client interface CVS folder. (Note that this script is not correct. You can also use the chec_prod_deps script).

5. Check the Metapackage changes. For each entry check the syntax is correct.

6. Check the External packages. If there are any, copy in the Integration repository afs area the package by doing a wget of the specified URL. If there's no URL, contact the developer to provide one. Remember that the external packages should also be included in the RPMs name field and in the Metapackage changes if they are to be added as a new dependency. The steps to be executed for external packages are:

mkdir -p /afs/cern.ch/project/gd/www/integration/repository/externals/package_name/x.y.z/platform
cd /afs/cern.ch/project/gd/www/integration/repository/externals/package_name/x.y.z/platform
wget The_provided_url/package_name.x.y.z-r.platform.rpm

Where platform is noarch, sl4, sl5,... and x.y.z is the version without including the revision number.

7. Check the Metapackages to be restarted and to be reconfigured. This is mostly the developers who know whether this is needed for a certain metapackage or not. So there's little to do here for the integrator but trusting the information. It would be good that the certifiers could confirm this information though.

8. Documentation, Configuration changes and Release notes. Check that all the necessary information is present and that it's good enough to perform configuration changes. In particular for the release notes think of whether the information is useful for production release notes and otherwise discuss with the developers on how to improve the text.

9. Check the status of the attached bugs and make sure they are in Ready for test.

10. Run in the machine where glite-release is installed

./scripts/move-patch -f -s cert -p <platform> <patch_number>

This is what this script does:

• Creates the patch definition file in glite-release/patches/ by extracting the list of rpms for a given patch from the Web Savannah patch information (Savannah field : "RPM names")
• Creates the patch changes file in glite/patches/_changes= by downloading the list of changes (Savannah field : "Metapackage changes")
• Creates the corresponding patch repository within the certification repository area, usually in $GD_AFS_DIR/cert/3.X/patches/

11. Check in http://grid-deployment.web.cern.ch/grid-deployment/glite/cert/3.X/patches/<patch-number> that the rpms are successfully created in the patch repository. In particular, check that in case there are metapackage changes, that the affected metapackages have a new cert--x.y.z-r.rpm in the patch repository.

e.g.

 
In a 3.1 32bit patch with these metapackage changes :
A|glite-WN|glite-test|
A|glite-WN|glite-test2|
R|glite-BDII|glite-version|

will result in :

># ls /afs/cern.ch/project/gd/www/glite/cert/3.1/patches/xxxx/sl4/i386/RPMS.xxxx/
..
cert-glite-BDII-3.1.0-0.i386.rpm
cert-glite-WN-3.1.0-0.i386.rpm

-- MariaALANDESPRADILLO - 27 Jan 2009