TODO NOW:
-- Make sure massmigrate cleanly ignores already migrated
- installs
-- Make sure MediaWiki repository is as close to perfect
- as possible:
- - Do an install, migrate and then `git status`
- - Check out possible missing php.ini's
- - Remove "Merge comments" from lines
- - Fix Signed-off-by lines
-- Add some safeguard code to make sure you don't run migrate
- or upgrade as root
-
-- We have safe, non-braindead
- version detection with `git describe --tags`. Switch
- everything to use it. (I think the only thing left is
- parallel-find.pl)
-- wizard.util is pretty braindead at this point. Fix up
- the wildly varying conventions in it.
-- Move migration code into Wizard, since we already deal
- with installation there anyway.
-
-- Better error message if daemon/scripts-security-upd
- is not on scripts-security-upd list
-
-- Fix retarded logging mechanism
-
-- The great initial deploy:
- - Turn on mediawiki new autoinstaller
- - Migrate all mediawiki installs
-
-Doing Wordpress:
-- Build automation for generating config files; this automation
- will be shared with the migrate script and the installer script
- (migrate script needs to be able to pull out values from config
- file, so will we; installer script needs to be able to run
- the installer to generate config files, so will this)
-- This should all be automated:
- - Wordpress needs to have .scripts dir in all -scripts versions
- (also make .scripts/.htaccess)
- - Wordpress needs to have a .scripts/update script written for
- its latest version (do this after its migration)
- - Wordpress needs to check for php.ini files (which it almost
- certianly has) and commit messages
- - Wordpress needs user config and php.ini links made
-
-- Summary script should be more machine friendly, and should not
- output summary charts when I increase specificity
-- Summary script needs to be updated for new format
-
-Some other stuff to do in your copious free time:
-- Check how many autoinstalls are missing w bits for
- daemon.scripts (this would need pyafs)
-- Make scripts AFS patch advertise its existence so we can check for it.
- (This might be otherwise possible using `fs sysname`
-- Implement proper deploy log parsing; this basically means we
- need to be able to introspect Git Log. Consider using git-python
- for this.
-- 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.
+- Make wizard install accept appname-head (so that you can do a test with
+ head, and do things without tags). Also make it accept commit hashes.
+ In fact, let it accept any committish. Figure out what to do if we
+ do a test script with x.y.z when we REALLY mean x.y.z-scripts. XXX!!!
+- Do early validation of inputs for configuration
+- Let 'wizard configure' be interactive
+- Parse output HTML for class="error" and give those errors back to the user,
+ then boot them back into configure
+
+- Replace gaierror with a more descriptive name (this is a DNS error)
+
+- 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.
+ - Move resolutions in mediawiki.py to a text file? (the parsing overhead
+ may not be worth it)
+ - 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. `php -l` can be a quick stopgap
+
+- 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
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
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.
- 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.
-
-- 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 (only allowed for serial processing)
- - default is OFF
- - log-file => loglevel = INFO
- x database logger (necessary for parallel processing, not implemented)
- - default is OFF
- - log-db => loglevel = INFO
-
-- More on the database logger: it will be very simple with one
- table named `logs` in SQLite, with columns: `job`, `level`,
- `message`. Job identifies the subprocess/thread that emitted
- the log, so things can be correlated together. We will then
- have `wizard dump` which takes a database like this and dumps
- it into a file logger type file. The database may also store
- a queue like structure which can be used to coordinate jobs.
+ also means that /mit/scripts/wizard/srv MUST NOT lose revs after
+ deployment.
OVERALL PLAN:
* 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.)
+ although uglier in some ways; A indicates the step /should/ be automated)
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
-A 1. Have the Git repository and working copy for the project on hand.
-
-A 2. Checkout the pristine branch
-
-A 3. Remove all files from the working copy. Use `wipe-working-dir`
+ 1. Have the Git repository and working copy for the project on hand.
-A 4. Download the new tarball
+ 2. Checkout the pristine branch
-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)
+ 3. Run wizard `prepare-pristine APP-VERSION`
-A 6. Check for empty directories and add stub files as necessary.
- Use `preserve-empty-dir`
+ X. Commit, with name "Appname x.y.z"
-A 7. Git add it all, and then commit as a new pristine version (v1.2.3)
+ 4. Checkout the master branch
-A 8. Checkout the master branch
-
- 9. [FOR EXISTING REPOSITORIES]
- Merge the pristine branch in. Resolve any conflicts that our
+ 5. 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 NEW REPOSITORIES]
- See if any patches are needed to make this run smoothly on
- scripts.
+ X. Commit, with name "Appname x.y.z-scripts". This is going to be
+ amended.
- [FOR NEW REPOSITORIES]
-A mkdir .scripts
-A echo "Deny from all" > .scripts/.htaccess
- touch .scripts/update
- chmod a+x .scripts/update
+ 6. 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. Commit with --amend, and
+ propagate back to your local copy (git reset --hard HEAD~; git pull afs).
- 10. Check if there are any special update procedures, and update/create 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.)
+ [ENTER HERE FROM CREATING A NEW REPO]
- 11. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if
- you are amending an install without an upstream changes)
+ 7. Check if there are any special update procedures, and update
+ the wizard.app.APPNAME module accordingly. If this is the first
+ time you are performing an upgrade, implement upgrade() in your
+ Application class. (XXX: extended instructions here). Test
+ the new update procedure using our test scripts (preferably
+ on a scripts server). Check this page for more info on our
+ integration tests:
- NOTE: These steps should be run on a scripts server
+ http://scripts.mit.edu/wizard/testing.html#acceptance-tests
- 12. Test the new update procedure using
- `wizard upgrade --with=/path/to/repo /your/autoinstall` (this will
- read out master as your "latest" version).
- Use git commit --amend to fix any bugs (alternatively, squash them
- together later).
+ 8. If you have any further changes, git commit --amend, and finally
+ tag as v1.2.3-scripts (or scripts2, if you are amending an install
+ without an upstream changes)
- 13. You can also do a "mass" version of this using:
- `wizard -d testbed.txt massupgrade --with=/path/to/repo app`
- You'll need perms for any testbed stuff you want. (not implemented)
+ 9. Push all of your changes in a public place, and encourage others
+ to test, using --srv-path and a full path.
- GET APPROVAL BEFORE PROCEEDING ANY FURTHER
+ GET APPROVAL BEFORE PROCEEDING ANY FURTHER;
+ THIS IS PUSHING THE CHANGES TO THE PUBLIC
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.
- 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.
- 15. Run `wizard massupgrade appname`, which applies the update to all working
- copies possible, and sends mail to users to whom the working copy
- did not apply cleanly.
-
- 16. Run parallel-find.pl to update our inventory
-
-* For mass importing into the repository, the steps are:
- (this probably won't ever be automated, becuase there are fiddly bits)
-
-[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 # [FIDDLY BIT]
-# 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 # [FIDDLY BIT]
-# 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 # [FIDDLY BIT]
-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
-[FIDDLE AROUND. FIDDLE AROUND]
-[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
+ 11. Run `wizard mass-upgrade appname`, which applies the update to all working
+ copies possible.
-* The repository for a given application will contain the following files:
+ 12. Run parallel-find.pl to update our inventory
- - The actual application's files, as from the official tarball
+* For mass importing into the repository, there are a few extra things:
+
+ * Many applications had patches associated with them. Be sure to
+ apply them, so later merges work better.
- - A .scripts directory, which contains the following information:
+ # the following operation might require -p1
+ patch -p0 < ../app-1.2.3/app-1.2.3.patch # [FIDDLY BIT]
- * .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. (XXX: This is going to get removed soon)
+ * When running updates, if the patch has changed you will have to
+ do a special procedure for your merge:
- * .scripts/.htaccess to prevent this directory from being accessed
- from the web.
+ 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
- * .scripts/old-version (optional) the old value of .scripts-version,
- basically used for reverting an install to pre-migrated state.
+ You could also just try your luck with a manual merge using the patch
+ as your guide.
- * .scripts/lock (generated) which locks the autoinstall during an upgrade
+* The repository for a given application will contain the following files:
+
+ - The actual application's files, as from the official tarball
+ - A .scripts directory, with the intent of holding Scripts specific files
+ if they become necessary.
+
+* Making the module files for a new application
+
+ 1. Create a wizard/app/APPNAME.py file. Create an object Application
+ inheriting from wizard.app.Application (check existing modules for
+ the boilerplate code).
+
+ 2. Implement download(). "wizard prepare-pristine" will use this in order
+ to download the next version of an application.
+
+ 3. Create a git repository with `git init`
+
+ 4. Use `wizard prepare-pristine APP-VERSION` to download the tarball and
+ extract it into the directory. If download() doesn't work and you don't
+ want to special case it (for example, you need a /really old version/
+ for record-keeping purposes), replace APP-VERSION with PATH, where PATH
+ is the tarball to extract.
+
+ 5. `git commit -asm "APP VERSION"`
+
+ 6. Check if any patches are needed to make the application work
+ on Scripts (ideally, it shouldn't.) Pre-existing patches
+ live in /mit/scripts/deploy/APP-VERSION/ directories.
+
+ 7. Run `wizard prepare-new` to setup common filesets for our repositories.
+
+ 8. 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.
+
+ 9. Do an initial commit (we're gonna be amending the hell of this)
+ using `git commit -asm "APP VERSION-scripts"
+
+ 10. Implement install(). Test using `wizard install APP`; you won't
+ be able to do a version-specific install with `wizard install APP-VERSION`
+ until you generate a tag (which will become out of date once you
+ amend the commit.) Now might be a good time to create a
+ tests/test-install-APP.sh file (use the other tests as reference) so
+ you don't have to constantly enter the parameters when you're doing
+ an install.
+
+ 11. Push your changes to a directory accessible in the production environment.
+ In the case of scripts, this is equivalent to your AFS homedir, and
+ the production environment is a scripts.mit.edu. We're going to
+ perform a configuration in the production environment to extract
+ out the canonical configuration files.
+
+ 12. On the production server, call your wizard to perform an installation;
+ be sure to use the option --no-commit in order to make propagating changes
+ back easier. Inspect the generated configuration files (you can use `git
+ status` to find unversioned files that the installer created), and
+ implement:
+ - extractors
+ - substitutions
+ These are dictionaries of functions that perform extraction
+ and substitution of variables from config files. You don't
+ actually have to hand code them; you can app.make_extractors
+ and app.make_substitutions on a common dictionary. Check
+ out wizard/app/__init__.py for more information on this
+ format, as well as other files for samples.
+ (XXX: extended instructions here)
+ - parametrized_files
+ These are any files that contain WIZARD_* variables
+ - checkConfig()
+ This is a simple, fs based check on whether or not the application
+ was configured. Usually checking if some generated config file
+ is present is sufficient
+ - detectVersion()
+ You might be able to reuse machinery from extractors (namely, whatever
+ function you were using to generate regular expressions), or you might
+ need to code a custom regular expression to parse this out.
+ - deprecated_keys?
+ Usually you won't need this; use it if there's a configuration variable
+ that needs to get parametrized, but isn't actually necessary and
+ gets obsoleted in a later version. You probably won't know if that's
+ the case until later.
+
+ 13. With these implemented, `wizard prepare-config` should now work if you run
+ it on the installed copy. The configuration file should now contain only
+ generic WIZARD_* variables, and no user-specific config. If it is, your
+ script was buggy; try again.
+
+ 14. The current changes in the working copy should be merged in. Add any new
+ files, and then `git commit --amend`. `git push --force` to stick these
+ changes back in the "public" repository.
+
+ 15. In your local copy, you can pull the changes by doing `git reset --hard HEAD~`
+ and then a `git pull` from the relevant source. Otherwise, Git will complain
+ about a non-fast-forward.
+
+ 16. Congratulations! You've implemented the installation code for a new install.
+ Now goto "ENTER HERE FROM CREATING A NEW REPO" and finish the rest of the
+ instructions.
scripts.mit.edu / wizard.git / blobdiff