TODO

   1 The Git Autoinstaller
   2
   3 TODO NOW:
   4
   5 - Remove "already migrated" cruft that will accumulate if we do small
   6   --limit and then increase.
   7 - Allow to migrate just one user (user filtering of installs, also
   8   has userland capabilities, although it means we need some way of
   9   selectively publishing the versions directory)
  10 - Make migrate script rollback if it's interrupted (especially if
  11   by signal)
  12
  13 - Make parallel-find.pl use `sudo -u username git describe --tags`
  14   to determine version.  Make parallel-find.pl have this have greater
  15   precedence.  This also means, however, that we get
  16   full mediawiki-1.2.3-2-abcdef names (Have patch, pending testing and commit)
  17 - Make the installer use 'wizard install' /or/ do a migration
  18   after doing a normal install (the latter makes it easier
  19   for mass-rollbacks).
  20 - Have the upgrader do locking (.scripts/lock, probably)
  21
  22 - Relax MediaWiki regexes to terminate on semicolon, and not
  23   require its own line.
  24
  25 - Better error message if daemon/scripts-security-upd
  26   is not on scripts-security-upd list
  27
  28 - MediaWiki upgrade script does not give proper exit code;
  29   if it fails, so be sure to check for "Done" in the last 10 characters.
  30 - Custom merge algo: absolute php.ini symlinks to relative symlinks
  31 - Custom merge algo: re-constitute AdminSettings.php if missing.  It looks
  32   like this is the case for most 1.5.8 installs (check what the merges
  33   do in both directions).  All 1.11.0 installs except four have
  34   the other (check diff -u with all in /root)
  35
  36 - Make upgrade and install take version as a parameter
  37
  38 - Redo Wordpress conversion, with an eye for automating everything
  39   possible (such as downloading the tarball and unpacking)
  40
  41 - Genericize callAsUser and drop_priviledges in shell
  42 - Summary script should be more machine friendly, and should not
  43   output summary charts when I increase specificity
  44
  45 Some other stuff to do in your copious free time:
  46 - Summary script should do something intelligent when distinguishing
  47   between old-style and new-style installs
  48 - Check how many autoinstalls are missing w bits for
  49   daemon.scripts (this would need pyafs)
  50 - Make scripts AFS patch advertise its existence so we can check for it.
  51   (This might be otherwise possible using `fs sysname`)
  52 - Make 'wizard summary' generate nice pretty graphs of installs by date
  53   (more histograms, will need to check actual .scripts-version files.)
  54 - It should be able to handle installs like Django where there's a component
  55   that gets installed in web_scripts and another directory that gets installed
  56   in Scripts.
  57
  58 PULLING OUT CONFIGURATION FILES IN AN AUTOMATED MANNER
  59
  60 advancedpoll: Template file to fill out
  61 django: Noodles of template files
  62 gallery2: Multistage install process
  63 joomla: Template file
  64 mediawiki: One-step install process
  65 phpbb: Multistage install process
  66 phpical: Template file
  67 trac: NFC
  68 turbogears: NFC
  69 wordpress: Multistage install process
  70
  71 PHILOSOPHY ABOUT LOGGING
  72
  73 Logging is most useful when performing a mass run.  This
  74 includes things such as mass-migration as well as when running
  75 summary reports.  An interesting property about mass-migration
  76 or mass-upgrade, however, is that if they fail, they are
  77 idempotent, so an individual case can be debugged simply running
  78 the single-install equivalent with --debug on.  (This, indeed,
  79 may be easier to do than sifting through a logfile).
  80
  81 It is a different story when you are running a summary report:
  82 you are primarily bound by your AFS cache and how quickly you can
  83 iterate through all of the autoinstalls.  Checking if a file
  84 exists on a cold AFS cache may
  85 take several minutes to perform; on a hot cache the same report
  86 may take a mere 3 seconds.  When you get to more computationally
  87 expensive calculations, however, even having a hot AFS cache
  88 is not enough to cut down your runtime.
  89
  90 There are certain calculations that someone may want to be
  91 able to perform on manipulated data.  As such, this data should
  92 be cached on disk, if the process for extracting this data takes
  93 a long time.  Also, for usability sake, Wizard should generate
  94 the common case reports.
  95
  96 Ensuring that machine parseable reports are made, and then making
  97 the machinery to reframe this data, increases complexity.  Therefore,
  98 the recommendation is to assume that if you need to run iteratively,
  99 you'll have a hot AFS cache at your fingerprints, and if that's not
 100 fast enough, then cache the data.
 101
 102 COMMIT MESSAGE FIELDS:
 103
 104 Installed-by: username@hostname
 105 Pre-commit-by: Real Name <username@mit.edu>
 106 Upgraded-by: Real Name <username@mit.edu>
 107 Migrated-by: Real Name <username@mit.edu>
 108 Wizard-revision: abcdef1234567890
 109 Wizard-args: /wizard/bin/wizard foo bar baz
 110
 111 GIT COMMIT FIELDS:
 112
 113 Committer: Real Name <username@mit.edu>
 114 Author: lockername locker <lockername@scripts.mit.edu>
 115
 116 NOTES:
 117
 118 - It is not expected or required for update scripts to exist for all
 119   intervening versions that were present pre-migration; only for it
 120   to work on the most recent migration.
 121
 122 - Currently all repositories are initialized with --shared, which
 123   means they have basically ~no space footprint.  However, it
 124   also means that /mit/scripts/wizard/srv MUST NOT lose revs after
 125   deployment.
 126
 127 - Full fledged logging options. Namely:
 128   x all loggers (delay implementing this until we actually have debug stmts)
 129     - default is WARNING
 130     - debug     => loglevel = DEBUG
 131   x stdout logger
 132     - default is WARNING (see below for exception)
 133     - verbose   => loglevel = INFO
 134   x file logger (creates a dir and lots of little logfiles)
 135     - default is OFF
 136     - log-file   => loglevel = INFO
 137
 138 OVERALL PLAN:
 139
 140 * Some parts of the infrastructure will not be touched, although I plan
 141   on documenting them.  Specifically, we will be keeping:
 142
 143     - parallel-find.pl, and the resulting
 144       /mit/scripts/.htaccess/scripts/sec-tools/store/scriptslist
 145
 146 * The new procedure for generating an update is as follows:
 147   (check out the mass-migration instructions for something in this spirit,
 148   although uglier in some ways; A indicates the step /should/ be automated)
 149
 150     0. ssh into not-backward, temporarily give the daemon.scripts-security-upd
 151        bits by blanching it on system:scripts-security-upd, and run parallel-find.pl
 152
 153     1. Have the Git repository and working copy for the project on hand.
 154
 155 /- wizard prepare-pristine --
 156
 157 A   2. Checkout the pristine branch
 158
 159 A   3. Remove all files from the working copy.  Use `wipe-working-dir`
 160
 161 A   4. Download the new tarball
 162
 163 A   5. Extract the tarball over the working copy (`cp -R a/. b` works well,
 164        remember that the working copy is empty; this needs some intelligent
 165        input)
 166
 167 A   6. Check for empty directories and add stub files as necessary.
 168        Use `preserve-empty-dir`
 169
 170 \---
 171
 172     7. Git add it all, and then commit as a new pristine version (v1.2.3)
 173
 174     8. Checkout the master branch
 175
 176     9. [FOR EXISTING REPOSITORIES]
 177        Merge the pristine branch in. Resolve any conflicts that our
 178        patches have with new changes. Do NOT let Git auto-commit it
 179        with --no-commit (otherwise, you want to git commit --amend
 180        to keep our history clean
 181
 182        [FOR NEW REPOSITORIES]
 183        Check if any patches are needed to make the application work
 184        on Scripts (ideally, it shouldn't.
 185
 186 /- wizard prepare-new --
 187
 188     Currently not used for anything besides parallel-find.pl, but
 189     we reserve the right to place files in here in the future.
 190
 191 A       mkdir .scripts
 192 A       echo "Deny from all" > .scripts/.htaccess
 193
 194 \---
 195
 196    10. Check if there are any special update procedures, and update
 197        the wizard.app.APPNAME module accordingly (or create it, if
 198        need be).
 199
 200    11. Run 'wizard prepare-config' on a scripts server while in a checkout
 201        of this newest version.  This will prepare a new version of the
 202        configuration file based on the application's latest installer.
 203        Manually merge back in any custom changes we may have made.
 204        Check if any of the regular expressions need tweaking by inspecting
 205        the configuration files for user-specific gunk, and modify
 206        wizard.app.APPNAME accordingly.
 207
 208    12. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if
 209        you are amending an install without an upstream changes)
 210
 211       NOTE: These steps should be run on a scripts server
 212
 213    13. Test the new update procedure using our test scripts.  See integration
 214        tests for more information on how to do this.
 215
 216         http://scripts.mit.edu/wizard/testing.html#acceptance-tests
 217
 218       GET APPROVAL BEFORE PROCEEDING ANY FURTHER
 219
 220       NOTE: The following commands are to be run on not-backward.mit.edu.
 221       You'll need to add daemon.scripts-security-upd to
 222       scripts-security-upd to get bits to do this.  Make sure you remove
 223       these bits when you're done.
 224
 225 A  14. Run `wizard research appname`
 226        which uses Git commands to check how many
 227        working copies apply the change cleanly, and writes out a logfile
 228        with the working copies that don't apply cleanly.  It also tells
 229        us about "corrupt" working copies, i.e. working copies that
 230        have over a certain threshold of changes.
 231
 232 A  15. Run `wizard mass-upgrade appname`, which applies the update to all working
 233        copies possible, and sends mail to users to whom the working copy
 234        did not apply cleanly.
 235
 236    16. Run parallel-find.pl to update our inventory
 237
 238 * For mass importing into the repository, there are a few extra things:
 239
 240     * Many applications had patches associated with them.  Be sure to
 241       apply them, so later merges work better.
 242
 243         # the following operation might require -p1
 244         patch -p0 < ../app-1.2.3/app-1.2.3.patch  # [FIDDLY BIT]
 245
 246     * When running updates, if the patch has changed you will have to
 247       do a special procedure for your merge:
 248
 249         git checkout pristine
 250         # NOTE: Now, the tricky part (this is different from a real update)
 251         git symbolic-ref HEAD refs/heads/master
 252         # NOTE: Now, we think we're on the master branch, but we have
 253         # pristine copy checked out
 254         # NOTE: -p0 might need to be twiddled
 255         patch -p0 < ../app-1.2.3/app-1.2.3.patch
 256         git add .
 257         # reconstitute .scripts directory
 258         git checkout v1.2.2-scripts -- .scripts
 259         git add .scripts
 260         # NOTE: Fake the merge
 261         git rev-parse pristine > .git/MERGE_HEAD
 262
 263       You could also just try your luck with a manual merge using the patch
 264       as your guide.
 265
 266 * The repository for a given application will contain the following files:
 267
 268     - The actual application's files, as from the official tarball
 269
 270     - A .scripts directory, with the intent of holding Scripts specific files
 271       if they become necessary.
 272
 273         * .scripts/lock (generated) which locks an autoinstall during upgrade
 274