]> scripts.mit.edu Git - wizard.git/blobdiff - TODO
Update TODO.
[wizard.git] / TODO
diff --git a/TODO b/TODO
index 284c08814f839ebe6e12a6e8f130613d166a27bb..f5280bb8ce1b29150088522da056cc0e756a1d53 100644 (file)
--- a/TODO
+++ b/TODO
@@ -2,27 +2,108 @@ The Git Autoinstaller
 
 TODO NOW:
 
 
 TODO NOW:
 
-- For the long running programs, I definitely want to use logging.
-- Whiteboard the flow for performing an upgrade on a single
-  install. How assisted does it need to be?
-- Conduct migration tool testing
-- Create mass-migration tool (should be able to limit on mediawiki)
-- Run parallel-find.pl
-- Migrate all mediawikis
-- Wordpress needs to have a .scripts/update script written for
-  its latest version
+- Keep my sanity when upgrading 1000 installs
+    - Replace gaierror with a more descriptive name (this is a DNS error)
+
+- Make the rest of the world use Wizard
+    - Make parallel-find.pl use `sudo -u username git describe --tags`
+      to determine version.  Make parallel-find.pl have this have greater
+      precedence.  This also means, however, that we get
+      full mediawiki-1.2.3-2-abcdef names (Have patch, pending testing and commit)
+    - Make deployed installer use 'wizard install' /or/ do a migration
+      after doing a normal install (the latter makes it easier
+      for mass-rollbacks).
+
+- Pre-emptively check if daemon/scripts-security-upd
+  is not on scripts-security-upd list (/mit/moira/bin/blanche)
+
+- Redo Wordpress conversion, with an eye for automating everything
+  possible (such as downloading the tarball and unpacking)
+
+- Web application for installing autoinstalls has a hard problem
+  with credentials (as well as installations that are not conducted
+  on an Athena machine.)  Possible solutions include asking the user
+  to SSH into an athena machine and run a bunch of commands, or writing
+  a Java applet (possibly in Clojure or Scala) which gets filesystem
+  permissions and then performs the operations.
+
+- Pay back code debt
+    - Genericize callAsUser and drop_priviledges in shell
+    - Summary script should be more machine friendly, and should not
+      output summary charts when I increase specificity
+    - Summary script should do something intelligent when distinguishing
+      between old-style and new-style installs
+    - Report code in wizard/command/__init__.py is ugly as sin.  Also,
+      the Report object should operate at a higher level of abstraction
+      so we don't have to manually increment fails. (in fact, that should
+      probably be called something different).  The by-percent errors should
+      also be automated.
+    - Indents in upgrade.py are getting pretty ridiculous; more breaking
+      into functions is probably a good idea
+    - Move resolutions in mediawiki.py to a text file? (the parsing overhead
+      may not be worth it)
+    - Investigate QuotaParseErrors
+    - If a process is C-ced, it can result in a upgrade that has
+      an updated filesystem but not updated database. Make this more
+      resilient
+    - PHP end of file allows omitted semicolon, can result in parse error
+      if merge resolutions aren't careful.
+
+- Other stuff
+    - Make single user mass-migrate work when not logged in as root
+    - Don't use the scripts heuristics unless we're on scripts with the
+      AFS patch.  Check with `fs sysname`
+    - Make 'wizard summary' generate nice pretty graphs of installs by date
+      (more histograms, will need to check actual .scripts-version files.)
+    - It should be able to handle installs like Django where there's a component
+      that gets installed in web_scripts and another directory that gets installed
+      in Scripts.
+    - ACLs is a starting point for sending mail to users, but it has
+      several failure modes:
+        - Old maintainers who don't care who are still on the ACL
+        - Private AFS groups that aren't mailing lists and that we
+          can't get to
+      A question is whether or not sending mail actually helps us:
+      many users will probably have to come back to us for help; many
+      other users won't care.
+
+PULLING OUT CONFIGURATION FILES IN AN AUTOMATED MANNER
+
+advancedpoll: Template file to fill out
+django: Noodles of template files
+gallery2: Multistage install process
+joomla: Template file
+mediawiki: One-step install process
+phpbb: Multistage install process
+phpical: Template file
+trac: NFC
+turbogears: NFC
+wordpress: Multistage install process
+
+COMMIT MESSAGE FIELDS:
+
+Installed-by: username@hostname
+Pre-commit-by: Real Name <username@mit.edu>
+Upgraded-by: Real Name <username@mit.edu>
+Migrated-by: Real Name <username@mit.edu>
+Wizard-revision: abcdef1234567890
+Wizard-args: /wizard/bin/wizard foo bar baz
+
+GIT COMMIT FIELDS:
+
+Committer: Real Name <username@mit.edu>
+Author: lockername locker <lockername@scripts.mit.edu>
 
 NOTES:
 
 
 NOTES:
 
-- A perfectly formed autoinstall with upgrade paths for all of
-  the intervening versions is not really feasible to implement.
-  As such, we want to migrate everything to -scripts, and then
-  generate a -scripts2 with the correct .scripts directory.
-  We will then nop update some installs, but this will prevent
-  us from having to migrate and update concurrently.
+- 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.
 
 
-- summary and info are still not using loggers. Maybe they should,
-  maybe they shouldn't
+- Currently all repositories are initialized with --shared, which
+  means they have basically ~no space footprint.  However, it
+  also means that /mit/scripts/wizard/srv MUST NOT lose revs after
+  deployment.
 
 OVERALL PLAN:
 
 
 OVERALL PLAN:
 
@@ -30,191 +111,113 @@ OVERALL PLAN:
   on documenting them.  Specifically, we will be keeping:
 
     - parallel-find.pl, and the resulting
   on documenting them.  Specifically, we will be keeping:
 
     - parallel-find.pl, and the resulting
-/mit/scripts/sec-tools/store/scriptslist
+      /mit/scripts/.htaccess/scripts/sec-tools/store/scriptslist
 
 
-    - The current install scripts will be kept in place, sans changes
-      necessary to make them use Git install of copying the script over.
-      Porting these scripts to Python and making them modular would be
-      nice, but is priority.  For the long term, seeing this scripts
-      be packaged with rest of our code would be optimal.
+* The new procedure for generating an update is as follows:
+  (check out the mass-migration instructions for something in this spirit,
+  although uglier in some ways; A indicates the step /should/ be automated)
 
 
-* The new procedure for generating an update is as follows (this is
-  also similar to procedure for creating these repositories):
+    0. ssh into not-backward, temporarily give the daemon.scripts-security-upd
+       bits by blanching it on system:scripts-security-upd, and run parallel-find.pl
 
     1. Have the Git repository and working copy for the project on hand.
 
     2. Checkout the pristine branch
 
 
     1. Have the Git repository and working copy for the project on hand.
 
     2. Checkout the pristine branch
 
-    3. Remove all files from the working copy (rm -Rf *, and then delete
-       any dot stragglers.  A script to do this would be handy)
+    3. Run wizard `prepare-pristine APP-VERSION`
 
 
-    4. Download the new tarball
+    4. Checkout the master branch
 
 
-    5. Extract the tarball over the working copy (`cp -R a/. b` works well,
-       remember that the working copy is empty)
-
-    6. Check for empty directories and add stub files as necessary
-       (use preserve-empty-dir)
-
-    7. Git add it all, and then commit as a new pristine version (v1.2.3)
-
-    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
        to keep our history clean
 
        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
        to keep our history clean
 
-       [FOR THE FIRST TIME]
-       Apply the scripts patch that was used for that version here
-       (usually patch -p1 < patch)
+       [FOR NEW REPOSITORIES]
+       Check if any patches are needed to make the application work
+       on Scripts (ideally, it shouldn't.)  Run
+       `wizard prepare-new` to setup common filesets for our repositories.
 
 
-   10. Check if there are any special update procedures, and update the
-       .scripts/update shell script as necessary (this means that any
-       application specific update logic will be kept with the actual
-       source code.  The language of this update script will vary
-       depending on context.)
+       If you are running a PHP script, there is usually a php.ini file
+       that we package.  You can see previous instances of this patch
+       at /mit/scripts/deploy/php.ini/ as well as in the repositories
+       of any already migrated scripts.  We hope to make these changes
+       unnecessary once PHP 5.3 arrives.
 
 
-   11. Commit your changes, and tag as v1.2.3-scripts
+    6. Check if there are any special update procedures, and update
+       the wizard.app.APPNAME module accordingly (or create it, if
+       need be).
 
 
-   If you're setting up a repository from scratch, stop here, and
-   repeat as necessary
+    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.
+       Check if any of the regular expressions need tweaking by inspecting
+       the configuration files for user-specific gunk, and modify
+       wizard.app.APPNAME accordingly.
 
 
-       XXX: Should we force people to push to the real repository at
-       this point, or just make the repository that the script pulls
-       stuff out of configurable? (Twiddling origin can get you a
-       devel setup with no code changes)
+    8. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if
+       you are amending an install without an upstream changes)
 
 
-   12. Run the "dry-run script", 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.
-
-   13. Run the "limited run" script, which applies the update to our
-       test-bed, and lets us check the basic functionality of the update.
-       This can include a script that lets us update a single directory
-       with verbose output.
-
-   14. Run the "deploy" script, which applies the update to all working
-       copies possible, and sends mail to users to whom the working copy
-       did not apply cleanly. It also frobs .scripts/version for successful
-       upgrades.
-
-   15. Run parallel-find.pl
-
-* For mass importing into the repository, the steps are:
-
-[TO SET IT UP]
-# let app-1.2.3 be the scripts folder originally in deploydev
-# let this folder be srv/
-# you can also do a git clone
-    mkdir app
-    cd app
-    git init
-    cd ..
-unfurl app-1.2.3 app
-# NOTE: contents of application are now in app directory
-cd app
-git add .
-git commit -s -m "App 1.2.3"
-git tag v1.2.3
-git branch pristine
-# NOTE: you're still on master branch
-# WARNING: the following operation might require -p1
-patch -p0 < ../app-1.2.3/app-1.2.3.patch
-# NOTE: please sanity check the patch!
-git add .
-# NOTE: -a flag is to handle if the patch deleted something
-git commit -as -m "App 1.2.3-scripts"
-git tag v1.2.3-scripts
-
-[TO ADD AN UPDATE]
-# let this folder be srv/app.git
-git checkout pristine
-# NOTE: this preserves your .git folder, but removes everything
-wipe-working-dir .
-cd ..
-unfurl app-1.2.3 app
-cd app
-# NOTE: please sanity check app directory
-git add .
-# NOTE: -a is to take care of deletions
-git commit -as -m "App 1.2.3"
-git tag v1.2.3
-[IF THE PATCH HAS CHANGED]
-    # You are on the pristine branch
-    # NOTE: Now, the tricky part (this is different from a real update)
-    git symbolic-ref HEAD refs/heads/master
-    # NOTE: Now, we think we're on the master branch, but we have
-    # pristine copy checked out
-    # NOTE: -p0 might need to be twiddled
-    patch -p0 < ../app-1.2.3/app-1.2.3.patch
-    git add .
-    # COMMENT: used to git checkout .scripts here
-    # then check if the directory needs an updated update script
-    # NOTE: Fake the merge
-    git rev-parse pristine > .git/MERGE_HEAD
-[IF THE PATCH HASN'T CHANGED]
-    git checkout master
-    git merge --no-commit pristine
-git commit -as -m "App 1.2.3-scripts"
-git tag v1.2.3-scripts
+      NOTE: These steps should be run on a scripts server
 
 
+    9. Test the new update procedure using our test scripts.  See integration
+       tests for more information on how to do this.
 
 
-* The repository for a given application will contain the following files:
+        http://scripts.mit.edu/wizard/testing.html#acceptance-tests
 
 
-    - The actual application's files, as from the official tarball
+      GET APPROVAL BEFORE PROCEEDING ANY FURTHER
 
 
-    - A .scripts directory, which contains the following information:
+      NOTE: The following commands are to be run on not-backward.mit.edu.
+      You'll need to add daemon.scripts-security-upd to
+      scripts-security-upd to get bits to do this.  Make sure you remove
+      these bits when you're done.
 
 
-        [IF THIS IS THE FIRST UPDATE]
-            mkdir .scripts
-            echo "Deny from all" > .scripts/.htaccess
-            touch .scripts/update
-            chmod a+x .scripts/update
-            # OPERATION: create the update script
+   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.
 
 
-        * .scripts/update shell script (with the +x bit set appropriately),
-          which performs the commands necessary to update a script.  This can
-          be in any language.
+   11. Run `wizard mass-upgrade appname`, which applies the update to all working
+       copies possible.
 
 
-        * .scripts/.htaccess to prevent this directory from being accessed
-          from the web.
+   12. Run parallel-find.pl to update our inventory
 
 
-        * .scripts/database (generated) contains the database the
-          user installed the script to, so scripts-remove can clean it
+* For mass importing into the repository, there are a few extra things:
 
 
-            XXX: Could cause problems if a user copies the autoinstall,
-            fiddles with the DB credentials, and then scripts-remove's
-            the autoinstall.  Possible fix is to add the original
-            directory as a sanity check.  Additionally, we could have
-            the application read out of this file.
+    * Many applications had patches associated with them.  Be sure to
+      apply them, so later merges work better.
 
 
-        * .scripts/version (generated) which contains the version
-          last autoinstalled (as distinct from the actual version
-          the script is) (This is the same as .scripts-version right
-          now; probably want to keep that for now)
+        # the following operation might require -p1
+        patch -p0 < ../app-1.2.3/app-1.2.3.patch  # [FIDDLY BIT]
 
 
-            XXX: It's unclear if we want to move to this wholesale, or
-            delay this indefinitely.
+    * When running updates, if the patch has changed you will have to
+      do a special procedure for your merge:
 
 
-* The migration process has been implemented, see 'wizard migrate'.
+        git checkout pristine
+        # NOTE: Now, the tricky part (this is different from a real update)
+        git symbolic-ref HEAD refs/heads/master
+        # NOTE: Now, we think we're on the master branch, but we have
+        # pristine copy checked out
+        # NOTE: -p0 might need to be twiddled
+        patch -p0 < ../app-1.2.3/app-1.2.3.patch
+        git add .
+        # reconstitute .scripts directory
+        git checkout v1.2.2-scripts -- .scripts
+        git add .scripts
+        # NOTE: Fake the merge
+        git rev-parse pristine > .git/MERGE_HEAD
 
 
-    XXX: We have not decided what migration should do to .scripts-version;
-    if it does move it to .scripts, repositories should have a .gitignore
-    in those directories
+      You could also just try your luck with a manual merge using the patch
+      as your guide.
 
 
-* The autoupgrade shall be the process of:
+* The repository for a given application will contain the following files:
 
 
-    # Make the directory not accessible by the outside world (htaccess, but be careful!)
-    git add -u .
-    git commit -m 'automatically generated backup'
-    git pull origin master
-    if [ $? ne 0 ]; then git reset --hard; echo 'conflicts during upgrade'; fi
-    ./.scripts/update
-    # Make it accessible
+    - The actual application's files, as from the official tarball
 
 
-  (with some more robust error checking)
+    - A .scripts directory, with the intent of holding Scripts specific files
+      if they become necessary.
 
 
-* Make 'wizard summary' generate nice pretty graphs of installs by date
-  (more histograms, will need to check actual .scripts-version files.)