X-Git-Url: https://scripts.mit.edu/gitweb/wizard.git/blobdiff_plain/1b24dbc31994b3debde039d96927dda437aeb24e..94d8e2812d6708b8c4c180c8075f051dcca2e5ce:/TODO diff --git a/TODO b/TODO index 4cf3265..e54748b 100644 --- a/TODO +++ b/TODO @@ -73,37 +73,6 @@ trac: NFC turbogears: NFC wordpress: Multistage install process -PHILOSOPHY ABOUT LOGGING - -Logging is most useful when performing a mass run. This -includes things such as mass-migration as well as when running -summary reports. An interesting property about mass-migration -or mass-upgrade, however, is that if they fail, they are -idempotent, so an individual case can be debugged simply running -the single-install equivalent with --debug on. (This, indeed, -may be easier to do than sifting through a logfile). - -It is a different story when you are running a summary report: -you are primarily bound by your AFS cache and how quickly you can -iterate through all of the autoinstalls. Checking if a file -exists on a cold AFS cache may -take several minutes to perform; on a hot cache the same report -may take a mere 3 seconds. When you get to more computationally -expensive calculations, however, even having a hot AFS cache -is not enough to cut down your runtime. - -There are certain calculations that someone may want to be -able to perform on manipulated data. As such, this data should -be cached on disk, if the process for extracting this data takes -a long time. Also, for usability sake, Wizard should generate -the common case reports. - -Ensuring that machine parseable reports are made, and then making -the machinery to reframe this data, increases complexity. Therefore, -the recommendation is to assume that if you need to run iteratively, -you'll have a hot AFS cache at your fingerprints, and if that's not -fast enough, then cache the data. - COMMIT MESSAGE FIELDS: Installed-by: username@hostname @@ -120,7 +89,7 @@ Author: lockername locker NOTES: -- It is not expected or required for update scripts to exist for all +- It is not required nor expected for update scripts to exist for all intervening versions that were present pre-migration; only for it to work on the most recent migration. @@ -129,17 +98,6 @@ NOTES: also means that /mit/scripts/wizard/srv MUST NOT lose revs after deployment. -- Full fledged logging options. Namely: - x all loggers (delay implementing this until we actually have debug stmts) - - default is WARNING - - debug => loglevel = DEBUG - x stdout logger - - default is WARNING (see below for exception) - - verbose => loglevel = INFO - x file logger (creates a dir and lots of little logfiles) - - default is OFF - - log-file => loglevel = INFO - OVERALL PLAN: * Some parts of the infrastructure will not be touched, although I plan @@ -157,28 +115,13 @@ OVERALL PLAN: 1. Have the Git repository and working copy for the project on hand. -/- wizard prepare-pristine -- - -A 2. Checkout the pristine branch - -A 3. Remove all files from the working copy. Use `wipe-working-dir` - -A 4. Download the new tarball - -A 5. Extract the tarball over the working copy (`cp -R a/. b` works well, - remember that the working copy is empty; this needs some intelligent - input) - -A 6. Check for empty directories and add stub files as necessary. - Use `preserve-empty-dir` + 2. Checkout the pristine branch -\--- + 3. Run wizard `prepare-pristine APP-VERSION` - 7. Git add it all, and then commit as a new pristine version (v1.2.3) + 4. Checkout the master branch - 8. Checkout the master branch - - 9. [FOR EXISTING REPOSITORIES] + 5. [FOR EXISTING REPOSITORIES] Merge the pristine branch in. Resolve any conflicts that our patches have with new changes. Do NOT let Git auto-commit it with --no-commit (otherwise, you want to git commit --amend @@ -186,23 +129,14 @@ A 6. Check for empty directories and add stub files as necessary. [FOR NEW REPOSITORIES] Check if any patches are needed to make the application work - on Scripts (ideally, it shouldn't. - -/- wizard prepare-new -- - - Currently not used for anything besides parallel-find.pl, but - we reserve the right to place files in here in the future. + on Scripts (ideally, it shouldn't.) Run + `wizard prepare-new` to setup common filesets for our repositories. -A mkdir .scripts -A echo "Deny from all" > .scripts/.htaccess - -\--- - - 10. Check if there are any special update procedures, and update + 6. Check if there are any special update procedures, and update the wizard.app.APPNAME module accordingly (or create it, if need be). - 11. Run 'wizard prepare-config' on a scripts server while in a checkout + 7. Run 'wizard prepare-config' on a scripts server while in a checkout of this newest version. This will prepare a new version of the configuration file based on the application's latest installer. Manually merge back in any custom changes we may have made. @@ -210,12 +144,12 @@ A echo "Deny from all" > .scripts/.htaccess the configuration files for user-specific gunk, and modify wizard.app.APPNAME accordingly. - 12. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if + 8. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if you are amending an install without an upstream changes) NOTE: These steps should be run on a scripts server - 13. Test the new update procedure using our test scripts. See integration + 9. Test the new update procedure using our test scripts. See integration tests for more information on how to do this. http://scripts.mit.edu/wizard/testing.html#acceptance-tests @@ -227,18 +161,17 @@ A echo "Deny from all" > .scripts/.htaccess scripts-security-upd to get bits to do this. Make sure you remove these bits when you're done. -A 14. Run `wizard research appname` + 10. Run `wizard research appname` which uses Git commands to check how many working copies apply the change cleanly, and writes out a logfile with the working copies that don't apply cleanly. It also tells us about "corrupt" working copies, i.e. working copies that have over a certain threshold of changes. -A 15. Run `wizard mass-upgrade appname`, which applies the update to all working - copies possible, and sends mail to users to whom the working copy - did not apply cleanly. + 11. Run `wizard mass-upgrade appname`, which applies the update to all working + copies possible. - 16. Run parallel-find.pl to update our inventory + 12. Run parallel-find.pl to update our inventory * For mass importing into the repository, there are a few extra things: @@ -275,5 +208,3 @@ A 15. Run `wizard mass-upgrade appname`, which applies the update to all workin - A .scripts directory, with the intent of holding Scripts specific files if they become necessary. - * .scripts/lock (generated) which locks an autoinstall during upgrade -