TODO

   1 The Git Autoinstaller
   2
   3 TODO NOW:
   4
   5 - Better error message if daemon/scripts-security-upd
   6   is not on scripts-security-upd list
   7
   8 - Add repository flag so that we can specify an
   9   arbitrary repository to migrate to
  10 - Fix retarded logging mechanism
  11
  12 - The great initial deploy:
  13     - Turn on mediawiki new autoinstaller
  14     - Migrate all mediawiki installs
  15
  16 - Testing:
  17     - Need a scriptable autoinstaller, which means we rewrite
  18       all of the autoinstall machinery.  This doesn't need
  19       to be able to create pre-wizard autoinstalls, since migration
  20       is easy to test+revert
  21
  22 - Build automation for generating config files; this automation
  23   will be shared with the migrate script and the installer script
  24   (migrate script needs to be able to pull out values from config
  25   file, so will we; installer script needs to be able to run
  26   the installer to generate config files, so will this)
  27
  28 - Implement proper deploy log parsing; this basically means we
  29   need to be able to introspect Git Log. Consider using git-python
  30   for this.
  31
  32 - This should all be automated:
  33     - Wordpress needs to have .scripts dir in all -scripts versions
  34       (also make .scripts/.htaccess)
  35     - Wordpress needs to have a .scripts/update script written for
  36       its latest version (do this after its migration)
  37     - Wordpress needs to check for php.ini files (which it almost
  38       certianly has) and commit messages
  39     - Wordpress needs user config and php.ini links made
  40
  41 - Summary script should be more machine friendly, and should not
  42   output summary charts when I increase specificity
  43 - Summary script needs to be updated for new format
  44 - Check how many autoinstalls are missing w bits for
  45   daemon.scripts (this would need pyafs)
  46 - Make scripts AFS patch advertise its existence so we can check for it
  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 - A perfectly formed autoinstall with upgrade paths for all of
 109   the intervening versions is not really feasible to implement.
 110   As such, we want to migrate everything to -scripts, and then
 111   generate a -scripts2 with the correct .scripts directory.
 112   We will then nop update some installs, but this will prevent
 113   us from having to migrate and update concurrently.  Treat
 114   a scripts2 upgrade from migration the same way you would treat
 115   a botched scripts upgrade.
 116     ADDENDUM: You MUST NOT migrate to a -scripts2 version; the
 117     machinery can't actually handle this.
 118
 119 - Currently all repositories are initialized with --shared, which
 120   means they have basically ~no space footprint.  However, it
 121   also means that /mit/scripts/wizard/srv MUST NOT lose revs.
 122
 123 - Full fledged logging options. Namely:
 124   x all loggers (delay implementing this until we actually have debug stmts)
 125     - default is WARNING
 126     - debug     => loglevel = DEBUG
 127   x stdout logger
 128     - default is WARNING (see below for exception)
 129     - verbose   => loglevel = INFO
 130   x file logger (only allowed for serial processing)
 131     - default is OFF
 132     - log-file   => loglevel = INFO
 133   x database logger (necessary for parallel processing, not implemented)
 134     - default is OFF
 135     - log-db    => loglevel = INFO
 136
 137 - More on the database logger: it will be very simple with one
 138   table named `logs` in SQLite, with columns: `job`, `level`,
 139   `message`.  Job identifies the subprocess/thread that emitted
 140   the log, so things can be correlated together.  We will then
 141   have `wizard dump` which takes a database like this and dumps
 142   it into a file logger type file.  The database may also store
 143   a queue like structure which can be used to coordinate jobs.
 144
 145 OVERALL PLAN:
 146
 147 * Some parts of the infrastructure will not be touched, although I plan
 148   on documenting them.  Specifically, we will be keeping:
 149
 150     - parallel-find.pl, and the resulting
 151       /mit/scripts/.htaccess/scripts/sec-tools/store/scriptslist
 152
 153 * The new procedure for generating an update is as follows:
 154   (check out the mass-migration instructions for something in this spirit,
 155   although uglier in some ways)
 156
 157     0. ssh into not-backward, temporarily give the daemon.scripts-security-upd
 158        bits by blanching it on system:scripts-security-upd, and run parallel-find.pl
 159
 160 A   1. Have the Git repository and working copy for the project on hand.
 161
 162 A   2. Checkout the pristine branch
 163
 164 A   3. Remove all files from the working copy.  Use `wipe-working-dir`
 165
 166 A   4. Download the new tarball
 167
 168 A   5. Extract the tarball over the working copy (`cp -R a/. b` works well,
 169        remember that the working copy is empty; this needs some intelligent
 170        input)
 171
 172 A   6. Check for empty directories and add stub files as necessary.
 173        Use `preserve-empty-dir`
 174
 175 A   7. Git add it all, and then commit as a new pristine version (v1.2.3)
 176
 177 A   8. Checkout the master branch
 178
 179     9. [FOR EXISTING REPOSITORIES]
 180        Merge the pristine branch in. Resolve any conflicts that our
 181        patches have with new changes. Do NOT let Git auto-commit it
 182        with --no-commit (otherwise, you want to git commit --amend
 183        to keep our history clean
 184
 185        [FOR NEW REPOSITORIES]
 186        See if any patches are needed to make this run smoothly on
 187        scripts.
 188
 189     [FOR NEW REPOSITORIES]
 190 A       mkdir .scripts
 191 A       echo "Deny from all" > .scripts/.htaccess
 192         touch .scripts/update
 193         chmod a+x .scripts/update
 194
 195    10. Check if there are any special update procedures, and update/create the
 196        .scripts/update shell script as necessary (this means that any
 197        application specific update logic will be kept with the actual
 198        source code.  The language of this update script will vary
 199        depending on context.)
 200
 201    11. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if
 202        you are amending an install without an upstream changes)
 203
 204       NOTE: These steps should be run on a scripts server
 205
 206    12. Test the new update procedure using
 207        `wizard upgrade --with=/path/to/repo /your/autoinstall` (this will
 208        read out master as your "latest" version).
 209        Use git commit --amend to fix any bugs (alternatively, squash them
 210        together later).
 211
 212    13. You can also do a "mass" version of this using:
 213        `wizard -d testbed.txt massupgrade --with=/path/to/repo app`
 214        You'll need perms for any testbed stuff you want. (not implemented)
 215
 216       GET APPROVAL BEFORE PROCEEDING ANY FURTHER
 217
 218       NOTE: The following commands are to be run on not-backward.mit.edu.
 219       You'll need to add daemon.scripts-security-upd to
 220       scripts-security-upd to get bits to do this.  Make sure you remove
 221       these bits when you're done.
 222
 223    14. Run `wizard research appname`
 224        which uses Git commands to check how many
 225        working copies apply the change cleanly, and writes out a logfile
 226        with the working copies that don't apply cleanly.  It also tells
 227        us about "corrupt" working copies, i.e. working copies that
 228        have over a certain threshold of changes.
 229
 230    15. Run `wizard massupgrade appname`, which applies the update to all working
 231        copies possible, and sends mail to users to whom the working copy
 232        did not apply cleanly.
 233
 234    16. Run parallel-find.pl to update our inventory
 235
 236 * For mass importing into the repository, the steps are:
 237   (this probably won't ever be automated, becuase there are fiddly bits)
 238
 239 [TO SET IT UP]
 240 # let app-1.2.3 be the scripts folder originally in deploydev
 241 # let this folder be srv/
 242 # you can also do a git clone
 243     mkdir app
 244     cd app
 245     git init
 246     cd ..
 247 unfurl app-1.2.3 app  # [FIDDLY BIT]
 248 # NOTE: contents of application are now in app directory
 249 cd app
 250 git add .
 251 git commit -s -m "App 1.2.3"
 252 git tag v1.2.3
 253 git branch pristine
 254 # NOTE: you're still on master branch
 255 # WARNING: the following operation might require -p1
 256 patch -p0 < ../app-1.2.3/app-1.2.3.patch  # [FIDDLY BIT]
 257 # NOTE: please sanity check the patch!
 258 git add .
 259 # NOTE: -a flag is to handle if the patch deleted something
 260 git commit -as -m "App 1.2.3-scripts"
 261 git tag v1.2.3-scripts
 262
 263 [TO ADD AN UPDATE]
 264 # let this folder be srv/app.git
 265 git checkout pristine
 266 # NOTE: this preserves your .git folder, but removes everything
 267 wipe-working-dir .
 268 cd ..
 269 unfurl app-1.2.3 app  # [FIDDLY BIT]
 270 cd app
 271 # NOTE: please sanity check app directory
 272 git add .
 273 # NOTE: -a is to take care of deletions
 274 git commit -as -m "App 1.2.3"
 275 git tag v1.2.3
 276 [FIDDLE AROUND. FIDDLE AROUND]
 277 [IF THE PATCH HAS CHANGED]
 278     # You are on the pristine branch
 279     # NOTE: Now, the tricky part (this is different from a real update)
 280     git symbolic-ref HEAD refs/heads/master
 281     # NOTE: Now, we think we're on the master branch, but we have
 282     # pristine copy checked out
 283     # NOTE: -p0 might need to be twiddled
 284     patch -p0 < ../app-1.2.3/app-1.2.3.patch
 285     git add .
 286     # COMMENT: used to git checkout .scripts here
 287     # then check if the directory needs an updated update script
 288     # NOTE: Fake the merge
 289     git rev-parse pristine > .git/MERGE_HEAD
 290 [IF THE PATCH HASN'T CHANGED]
 291     git checkout master
 292     git merge --no-commit pristine
 293 git commit -as -m "App 1.2.3-scripts"
 294 git tag v1.2.3-scripts
 295
 296 * The repository for a given application will contain the following files:
 297
 298     - The actual application's files, as from the official tarball
 299
 300     - A .scripts directory, which contains the following information:
 301
 302         * .scripts/update shell script (with the +x bit set appropriately),
 303           which performs the commands necessary to update a script.  This can
 304           be in any language.
 305
 306         * .scripts/.htaccess to prevent this directory from being accessed
 307           from the web.
 308
 309         * .scripts/database (generated) contains the database the
 310           user installed the script to, so scripts-remove can clean it
 311
 312             XXX: Could cause problems if a user copies the autoinstall,
 313             fiddles with the DB credentials, and then scripts-remove's
 314             the autoinstall.  Possible fix is to add the original
 315             directory as a sanity check.  Additionally, we could have
 316             the application read out of this file.
 317
 318         * .scripts/old-version (optional) the old value of .scripts-version
 319
 320         * .scripts/version something like "app-1.2.3-scripts"
 321
 322         * .scripts/install (eventually) interactively installs the
 323           application from command line.  (This might go into wizard.app
 324           Python module)
 325
 326         * .scripts/lock which locks the autoinstall during an upgrade
 327
 328 * Make 'wizard summary' generate nice pretty graphs of installs by date
 329   (more histograms, will need to check actual .scripts-version files.)
 330