Please note that these Trac pages are no longer being updated. Wiki contents/documentation have moved to GitHub.


Version 17 (modified by gpress, 6 years ago)


Deploying a New Version

Explains how to go about deploying a new version of the code, which consists of two main steps: updating the files that the software updaters on each node check for updates, and replacing the base installers that are incorporated in new installations.

If you only want to make a release candidate build (or one that includes tests) available to the Custom Installer Builder, do not follow any of the steps on this page. Instead, see BaseInstallers and manually copy the created files to /var/www/dist on seattle.cs (but not

Step by Step

  1. Make sure the continuous build shows all tests passing (aside from any expected, non-critical failures such as new build machines not fully configured or flaky tests).
  2. First, we push the release to the betabox testbed and make sure all is well there before pushing it on the main (seattleclearinghouse) testbed.
    1. Log in to betabox ( as a user who has sudo privileges.
    2. cd /home/release
    3. Update to the current svn trunk: svn up trunk
    4. If new library files has been added since the last deployment then couple of extra steps need to be taken.
      • trunk/ needs to be edited to copy over the new library files that are new in this version.
      • trunk/dist/ and trunk/dist/ needs to be modified and the name of the new library files need to be added in. It will be in the form 'req NEW_LIB_FILE_NAME'.
    5. Edit the file trunk/nodemanager/ and change the version to whichever version you're releasing (e.g. version = "0.1m")
    6. At this point, we need to make sure that the only differences between our copy of trunk and what's in svn are the differences of the betabox software updater key and update url embedded in trunk/softwareupdater/ and the version string in trunk/nodemanager/ The files trunk/, trunk/dist/ and trunk/dist/ may also be different if you had to edit them in step 4.
      • Check what's different from svn: svn status trunk
      • You should see the following as 'M':
        • trunk/softwareupdater/
        • trunk/nodemanager/
      • If you svn diff these files, the output should look like these diffs Download.
    7. Now, we actually deploy the new version. Still from the /home/release directory, do the following (these are separate actions, their order does not matter):
      • To update the base installers used by Seattle Clearinghouse on betabox, run the following:
        • ./ VERSION_HERE
        • example output Download
      • To update existing clients (that is, to make the updated files available to clients that are checking the update site), run the following:
  3. Once the launch appears to have gone well on betabox (all nodes updated, we can acquire and use vessels from betabox's updated nodes), log on to the main seattle server (
    1. Make sure you are logged in as someone who will have full access to the update and base installer directories.
    2. Figure out which public and private keys you will use.
    3. Open trunk/nodemanager/ and find where the version constant is set.
    4. Change the value to the appropriate version (e.g., "0.1d").
    5. Navigate to trunk/dist.
    6. Run "python .. path/to/publickey path/to/privatekey version".
      • Important: At this point, all nodes will be updating to the new version.
      • Pushing the update to all existing nodes (through the SoftwareUpdater?) is done by this script, not the remaining steps.
      • The remaining steps are only to make installers downloaded from Seattle Clearinghouse be the new version you are releasing.
    7. Navigate to the base installer directory (/var/www/dist as of January 2009).
    8. scp the new files here (these will be the versioned files, e.g. seattle_linux0.1d.tgz, and the unversioned files, e.g. seattle_linux.tgz) over to /home/custominstallerbuilder/live/custominstallerbuilder/html/static/installers/base/ (this is where the custom installer builder resides) on the seattle geni server (
    9. Remove any installers cached in /var/www/dist/geni/*_dist/. You can do rm -rf /var/www/dist/geni/*_dist/.