From 94d8e2812d6708b8c4c180c8075f051dcca2e5ce Mon Sep 17 00:00:00 2001 From: "Edward Z. Yang" Date: Fri, 23 Oct 2009 22:22:42 -0400 Subject: [PATCH] Update TODO. Signed-off-by: Edward Z. Yang --- TODO | 46 +--------------------------------------------- 1 file changed, 1 insertion(+), 45 deletions(-) diff --git a/TODO b/TODO index 31c1729..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 @@ -250,5 +208,3 @@ OVERALL PLAN: - A .scripts directory, with the intent of holding Scripts specific files if they become necessary. - * .scripts/lock (generated) which locks an autoinstall during upgrade - -- 2.45.0