Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

Releasing an ITB update

Prep work

  1. Coordinate with Suchandra Thapa, the OSG integration coordinator.
  2. Write release notes for the release to share with the ITB admins:
    cd /p/vdt/public/html/releases/2.0.0
    emacs release-pNUMBER.html
    

Updater process

Note: This process will take approximately 1 to 3 hours depending on the number of updated components.

  1. Stop services and make a backup on vdt-itb.cs.wisc.edu. This machine takes backups slowly, so do this in parallel with the release process. Suchandra does not do an update test (he does fresh installs) so it is essential we test the update ourselves before unleashing it on the ITB admins.
  2. If you built new tarballs on RHEL-5 platforms for Expat, Globus, LFC, or VOMS, then you need to update the LFC-Client-Lib32-Addon package (i.e. bump the release number in the defs file and run make-vdt on it), since it uses tarballs from those builds.
  3. Update the vdt-updater script in the -dev branch. In order to build the list of updated packages, use these methods. Use both and cross-check.
    • Look through SVN commits since the last release. Watch out for changes to defs files: These might imply changes to a package that didn't have a SVN commit. Double-check things like a change to the GUMS package: GUMS isn't re-made, but GUMS-Server and GUMS-Client are.
    • Find all changed files in SVN with subversion. The easiest way to do this is to start the merge (step 4 below) and look at what gets applied to the -test branch.
    • Add VDT-Version-Info to the list (and update the VDT_VERSION_INFO_REVISION if it is not already at the latest revision).
  4. Merge the changes from the VTB branch (-dev) to the ITB branch (-test). In order to figure out where to merge from look at the SVN commit history for the defs file in the -test branch.
  5. Make sure the defs file reflects the correct version and release number.
  6. Run make-vdt on the list you generated before. This will probably just be the same list of packages you put into VDT-Updater/updated-packages.xml but it might also include some packages that were changed but are not being updated to a new revision.
  7. Compare the -dev and -test branches to ensure that they are (almost) identical. The only differences should be where cache numbers are listed, such as these files:
    • defs
    • VDT-Updater/make-package
    • VDT-Updater/vdt/update/vdt-updater
  8. Start testing 2.0.99 and (most likely) stop testing 2.0.89.
  9. Have Suchandra update the ITB cache.
  10. IMPORTANT: Update our test ITB site (on vdt-itb.cs.wisc.edu). This is the only testing that the vdt-updater script will likely receive before the ITB admins. Things to look for during the update:
    • Did the update work? (Duh)
    • Check the vdt-updater.log file for any surprises.
    • Run vdt-version and make sure that nothing says "UPDATE AVAILABLE". Also make sure that the affected components list the version they should.
    • Turn the site back on and run some basic Globus jobs
    • Run "rsv-control --run --all-enabled" then check the HTML web page and in MyOSG (link may not work)
  11. Tell Suchandra to announce the release.