TODO

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