How to Cut a Release

Due to the length of time that this process takes, it is recommended to do the release over two days to allow for errors to be corrected and because some of the koji commands take a long time to run when a large number of rpms are being released.

This document doesn't discuss the policy for deciding what goes into a release. The release policy is discussed elsewhere.

NOTE Interactive scripts can be found at https://vdt.cs.wisc.edu/svn/software/release-tools/ and can be checked out with SVN.

Pick the version number

This page will help you get the various commands exactly right. To do this, enter the exact version number (such as 3.0.5) and click submit. If you do not do this, the commands below will be missing essential text.

Version: Upcoming:

Day 0

Step 1: Update the osg-version RPM

Edit the osg-version RPM's spec file to update the version number to VERSION. Build it in koji:

# If building for the latest release out of trunk:
osg-build koji osg-version
# If building for an older release out of a branch:
osg-build koji --repo=VERSION osg-version

Step 2: Generate the tentative release list

The release manager often needs a preliminary list of packages slated for the next release a few weeks in advance. This is done by finding the package differences between what's in testing and what's in the current release. It is also informative to find the package differences between what's in development and what's in testing. There is a script in SVN that handles this:

./0-generate-pkg-list VERSION

Day 1: Verify Pre-Release and Testing

Step 1: Double check the tentative release list

You will need to make sure that no packages were inadvertently left behind in development. This is done by finding the package differences between what's in development and what's in the testing. There is a script in SVN that handles this:

./0-generate-pkg-list VERSION

Step 2: Verify Pre-Release

You will need to compare the list of packages already in pre-release to the final list for the release put together by the OSG Release Coordinator. You can use the 1-list-prerelease script from SVN:

./1-list-prerelease VERSION

If there are any discrepancies you may have to tag or untag packages with the osg-koji tool.

NOTE: Please verify that the osg-version RPM is in your set of packages for the release! Also verify that if there is a new version of the osg-tested-internal RPM, then it is included in the release as well!

Step 3: Test Pre-Release in VM Universe

To test pre-release, you will be kicking off a manual VM universe test run from osghost.chtc.wisc.edu.

  1. Make sure you meet the pre-requisites for submitting VM universe test runs
  2. Prepare the test suite by running:
    osg-run-tests 'Testing OSG pre-release'
    
  3. cd into the directory specified in the output of the previous command
  4. cd into parameters.d and remove all files within it except for osg32.yaml, osg33-el6.yaml, and osg33-el7.yaml
  5. Edit osg32.yaml so that it reads:
    platform:
      - centos_5_x86_64
      - centos_6_x86_64
      - rhel_5_x86_64
      - rhel_6_x86_64
      - sl_5_x86_64
      - sl_6_x86_64
    
    sources:
      - trunk; 3.2; osg-prerelease                      # Tests clean installs of 3.2 pre-release
      - trunk; 3.2; osg > osg-prerelease                # Tests update installs of 3.2 pre-release
      - trunk; 3.1; osg > 3.2/osg-prerelease            # Tests update installs between 3.1 and 3.2 pre-release
    
    packages:
      - [java-1.7.0-openjdk-devel, osg-java7-compat, osg-java7-devel-compat, osg-tested-internal]
    
  6. Edit osg33-el6.yaml so that it reads:
    platform:
      - centos_6_x86_64
      - rhel_6_x86_64
      - sl_6_x86_64
    
    sources:
      - trunk; 3.3; osg-prerelease                      # Tests clean installs of 3.3 pre-release
      - trunk; 3.3; osg > osg-prerelease                # Tests update installs of 3.3 pre-release
      - trunk; 3.2; osg > 3.3/osg-prerelease            # Tests update installs between 3.2 and 3.3 pre-release
      - trunk; 3.1; osg > 3.3/osg-prerelease            # Tests update installs between 3.1 and 3.3 pre-release  
    
    
    packages:
      - [java-1.7.0-openjdk-devel, osg-java7-compat, osg-java7-devel-compat, osg-tested-internal]
    
  7. Edit osg33-el7.yaml so that it reads:
    platform:
      - centos_7_x86_64
      - rhel_7_x86_64
      - sl_7_x86_64
    
    sources:
      - trunk; 3.3; osg-prerelease                      # Tests clean installs of 3.3 pre-release
      - trunk; 3.3; osg > osg-prerelease                # Tests update installs of 3.3 pre-release
    
    
    packages:
      - [java-1.7.0-openjdk-devel, osg-java7-compat, osg-java7-devel-compat, osg-tested-internal]
    
  8. cd back into the root directory of the test run (e.g. cd ..)
  9. Submit the DAG:
    condor_submit_dag master-run.dag
    

NOTE: If there are failures, consult the release-manager before proceeding.

Step 4: Create the client tarballs

Create the client tarballs using the scripts in software/tarball-client/trunk from our SVN, and then copy them into the UW's AFS. Do this as root on an EL6 fermicloud machine. Change the username and machine name as appropriate. Note: the prerelease repos must have been populated and regenerated for this to work; normally that happens in Step 2.

ruser=matyas
rmachine=library.cs.wisc.edu
yum -y install git yum-priorities
cd /tmp
git clone --depth 1 https://github.com/opensciencegrid/tarball-client
tarball-client/make-client-tarball --osgver=VERSION --prerelease --all
scp -p *.i386.tar.gz $ruser@$rmachine:/p/vdt/public/html/tarball-client/VERSION/i386
scp -p *.x86_64.tar.gz $ruser@$rmachine:/p/vdt/public/html/tarball-client/VERSION/x86_64
You should get 8 tarballs, 30-55 megs each. They should all have VERSION in the name.

NOTE If you are running into 404 errors concerning specific packages, this may be due to stale build repos. To regenerate the build repos, run:

[user@client ~]$ osg-koji regen-repo osg-<osg version>-<distro version>-release-build

For example, run the following command to regenerate the OSG 3.2 EL6 build repo:

[user@client ~]$ osg-koji regen-repo osg-3.2-el6-release-build

Step 5: Briefly test the client tarballs

As an unprivileged user, extract each tarball into a separate directory. Make sure osg-post-install works. Make sure 'osgrun osg-version' works.

For 3.2:

for client in osg-client osg-wn-client; do
    for rhel in el5 el6; do
        for arch in i386 x86_64; do
            file=$client-VERSION-1.$rhel.$arch.tar.gz
            mkdir -p $rhel-$arch
            pushd $rhel-$arch
            tar xzf ../$file
            $client/osg/osg-post-install
            $client/osgrun osg-version
            popd
            rm -rf $rhel-$arch
        done
    done
done

For 3.3:

dotest () {
    file=$client-VERSION-1.$rhel.$arch.tar.gz
    mkdir -p $rhel-$arch
    pushd $rhel-$arch
    tar xzf ../$file
    $client/osg/osg-post-install
    $client/osgrun osg-version
    popd
    rm -rf $rhel-$arch
}

for client in osg-afs-client osg-wn-client; do
    for rhel in el6 el7; do
        arch=x86_64
        dotest
    done
done

client=osg-wn-client
arch=i386
rhel=el6
dotest

If you have time, try some of the binaries, such as grid-proxy-init.

NOTE: We need to automate this and have it run on the proper architectures and version of RHEL.

Step 6: Update the UW AFS installation of the tarball client

The UW keeps an install of the tarball client in /p/vdt/workspace/tarball-client on the UW's AFS. There is a script to update it called afs-install-tarball-client. Run it as follows:

/p/vdt/workspace/tarball-client/afs-install-tarball-client VERSION

Step 7: Wait

Wait for clearance. The OSG Release Coordinator (in consultation with the Software Team and any testers) need to sign off on the update before it is released. If you are releasing things over two days, this is a good place to stop for the day.


Day 2: Pushing the Release

NOTE: For the second phase of the release, try to complete it earlier in the day rather than later. The GOC would like to send out the release announcement prior to 3 p.m. their time (Eastern time zone), which means that our procedure needs to be completed before then.

Step 1: Push from pre-release to release

This script moves the packages into release, clones release into a new VERSION specific release repo, locks the new repo and regenerates it. Afterwards, it produces *release-note* files that should be given to whomever's writing the release notes.

./2-create-release VERSION

*.txt files are also created and it should be verified that they've been moved to /p/vdt/public/html/release-info/ on UW's AFS. There is also a section of the release notes that lists the packages that have been updated. To get this list, run:

list-package-updates VERSION

Step 2: Get the new CA certificates pushed to software.grid.iu.edu

If this release contains a new version of osg-ca-certs or igtf-ca-certs, submit a GOC ticket to have them propagate the CA certificates from the recently updated release repositories to software.grid.iu.edu and assign this ticket to Scott Teige:

Please run /opt/bin/install-latest-cache-files-new.sh on software1/2

Once the GOC has run their script, run the following command to update the CA certificates in the tarball installations and verify that the version of the CA certificates match the version that was promoted to release.

/p/vdt/workspace/tarball-client/current/amd64_rhel6/osgrun osg-update-certs
/p/vdt/workspace/tarball-client/current/amd64_rhel7/osgrun osg-update-certs

Step 3: Upload the client tarballs

Ask Tim Theisen or Brian Lin or someone with privileges on the grid.iu.edu repo servers to upload the tarballs with the following procedure:

On a CS machine

cd /p/vdt/public/html/tarball-client
ssh jump.grid.iu.edu mkdir /tmp/VERSION/
scp -p VERSION/*/*VERSION*gz jump.grid.iu.edu:/tmp/VERSION/

On jump.grid.iu.edu

rm -f /tmp/VERSION/*-afs-*
scp -pr /tmp/VERSION repo1:/tmp/
scp -pr /tmp/VERSION repo2:/tmp/
rm -rf /tmp/VERSION

On repo1/repo2 (as root)

You can ssh to repo1 and repo2 from jump.grid.iu.edu; you will need to do this procedure on both systems.
sudo su -
mv /tmp/VERSION /usr/local/repo/tarball-install/VERSION/
rm -f /usr/local/repo/tarball-install/VERSION/*latest*
/root/mk-sims.sh
ls -l /usr/local/repo/tarball-install/VERSION/*latest* # verify the symlinks are correct

Step 4: Install the tarballs into OASIS

You must be an OASIS manager of the 'mis' VO to do these steps. Known managers as of 2014-07-22: Mat, Tim C, Tim T, Brian L. Get the uploader script from Git and run it with osgrun from the UW AFS install of the tarball client you made earlier. On a UW CSL machine:

cd /tmp
git clone --depth 1 file:///p/vdt/workspace/git/repo/tarball-client.git
/p/vdt/workspace/tarball-client/current/sys/osgrun /tmp/tarball-client/upload-tarballs-to-oasis VERSION
The script will automatically ssh you to oasis-login.opensciencegrid.org and give you instructions to complete the process.

Step 5: Remove old UW AFS installations of the tarball client

To keep space usage down, remove tarball client installations and symlinks under /p/vdt/workspace/tarball-client that are more than 2 months old. The following command can list them:

find  /p/vdt/workspace/tarball-client  -maxdepth 1  -mtime +60  -name 3\*  -ls

Step 6: Announce the release

The following instructions are meant for the release manager (or interim release manager). If you are not the release manager, let the release manager know that they can announce the release.

  1. The release manager writes the release announcement and send it out. Here is a sample:

    Subject: Announcing OSG Software version VERSION

    We are pleased to announce OSG Software version VERSION!

    This is the new OSG Software distributed via RPMs for:

    * Scientific Linux 5 and 6
    * CentOS 5 and 6
    * Red Hat Enterprise Linux 5 and 6

    This release affects the SET-OF-METAPACKAGES (client, compute element, etc...). Changes include:

    * Major change 1
    * Major change 2
    * Major change 3

    Release notes and pointers to more documentation can be found at:

    https://www.opensciencegrid.org/bin/view/Documentation/Release3/ReleaseVERSION

    Need help? Let us know:

    https://www.opensciencegrid.org/bin/view/Documentation/Release3/HelpProcedure

    We welcome feedback on this release!

  2. The release manager emails the announcement to vdt-discuss@opensciencegrid.org
  3. The release manager asks the GOC to distribute the announcement by opening a ticket
  4. The release manager closes the tickets marked 'Ready for Release' in the release's JIRA filter
  5. The release manager updates the recent/scheduled release tables on the Software/Release homepage

Topic revision: r116 - 07 Apr 2016 - 18:19:30 - MatyasSelmeci
Hello, TWikiGuest
Register

 
TWIKI.NET

TWiki | Report Bugs | Privacy Policy

This site is powered by the TWiki collaboration platformCopyright by the contributing authors. All material on this collaboration platform is the property of the contributing authors..