TODO NOW:
-- Make it faster
- - Certain classes of error will continually fail, so they should
- put in a different "seen" file which also skips them, unless
- we have some sort of gentle force
-
-- Keep my sanity when upgrading 1000 installs
- - Distinguish between errors(?)
- - Custom merge algo: absolute php.ini symlinks to relative symlinks (this
- does not seem to have been a problem in practice)
- - Custom merge algo: check if it's got extra \r's in the file,
- and dos2unix it if it does, before performing the merge
- - `vos exa` in order to check what a person's quota is. We can
- figure out roughly how big the upgrade is going to be by
- doing a size comparison of the tars: `git pull` MUST NOT
- fail, otherwise things are left conflicted, and not easy to fix.
- - Prune -7 call errors and automatically reprocess them (with a
- strike out counter of 3)
- - Snap-in conflict resolution teaching:
- 1. View the merge conflicts after doing a short run
- 2. Identify common merge conflicts
- 3. Copypaste the conflict markers to the application. Scrub
- user-specific data; this may mean removing the entire
- upper bit which is the user-version.
- 4. Specify which section to keep. /Usually/ this means
- punting the new change, but if the top was specified
- it means we get a little more flexibility. Try to
- minimize wildcarding: those things need to be put into
- subpatterns and then reconstituted into the output.
- Example:
- Input:
- <<<<<<<
- ***1***
- =======
- upstream
- >>>>>>>
- Output:
- [1] # discard system string
- Input:
- <<<<<<<
- old upstream
- =======
- new upstream
- >>>>>>>
- Output:
- ['R'] # keep the new upstream string
- # This would be useful if a particular upstream change
- # is really close to where user changes are, so that
- # the conflict pops up a lot and it's actually spurious
- Input:
- <<<<<<<
- ***1***
- old upstream
- ***2***
- old upstream
- ***3***
- =======
- new upstream
- >>>>>>>
- Output:
- ['R', 1, 2, 3] # should be evident
- # it's not actually clear to me if this is useful
- To resolve: do we need the power of regexes? This might suck
- because it means we need to implement escaping. We might want
- simple globbing to the end of line since that's common in
- configuration files.
-
-- Distinguish from logging and reporting (so we can easily send mail
- to users)
- - Remove "already migrated" cruft that will accumulate if we do small
- --limit and then increase.
- - Logs aren't actually useful, /because/ most operations are idempotent.
- Thus, scratch logfile and make our report files more useful: error.log
- needs error information; we don't care too much about machinability.
- All report files should be overwritten on the next run, since we like
- using --limit to incrementally increase the number of things we run. Note
- that if we add soft ignores, you /do/ lose information, so there needs
- to be some way to also have the soft ignore report a "cached error"
- - Report the identifier number at the beginning of all of the stdout logs
- - Log files that already exist should be initialized with some sort
- of separator THAT CONTAINS THE LOCATION OF THE INSTALL
- - Don't really care about having the name in the logfile name, but
- have a lookup txt file
- - Figure out a way of collecting blacklist data from .scripts/blacklisted
- and aggregate it together
- - Failed migrations should be wired to have wizard commands in them
- automatically log to the relevant file. In addition, the seen file
- should get updated when one of them gets fixed.
- - Log files need to have dates, since it looks like upgrades will be
- multi-day affairs
- - Failed migration should report how many unmerged files there are
- (so we can auto-punt if it's over a threshold)
- - Verification failures should be written to a report file, possibly
- with short HTML fingerprints so we can inspect them easily and
- numbers to look at the log files
-
-- Let users use Wizard when ssh'ed into Scripts
- - Make single user mass-migrate work when not logged in as root
-
-- 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).
+- If you try to do an install on scripts w/o sql, it will sign you up but fail to write
+ the sql.cnf file. This sucks.
+
+- wizard install wordpress should ask for password. One problem with this is that
+ Wordpress will still send mail with the wrong username and password, so Wordpress
+ will need to be patched to not do that. Alternatively we can initally set the admin
+ email to a null address and then fix it manually.
+- --raw parameter for install which means an arbitrary commit can be installed
+- Parse output HTML for class="error" and give those errors back to the user (done),
+ then boot them back into configure so they can enter in something different
+- Get rid of our custom sizing code and use dialog's built-in sizing (i.e. width=0, height=0).
+ Maybe our sizing code is superior, maybe not.
+
+- 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.) We have some crazy ideas involving a signed
+ Java applet that uses jsch to SSH into athena.dialup and perform
+ operations.
- Pay back code debt
- - Genericize callAsUser and drop_priviledges in shell
+ - Tidy up common code in 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
+ - Figure out why Sphinx sometimes fails to crossref :func: but wil
+ crossref :meth:, even though the dest is very clearly a function.
+ Example: :func:`wizard.app.php.re_var`
+ - The TODO extension for Sphinx doesn't properly force a full-rebuild
+ - Code annotation!
+ - Make single user mass-migrate work when not logged in as root. The
+ primary difficulty is making the parallel-find information easily
+ accessible to individual users: perhaps we can do a single-user
+ parallel-find on the fly.
- 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
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.
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
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.
-
-/- 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`
-
-\---
-
- 7. Git add it all, and then commit as a new pristine version (v1.2.3)
-
- 8. Checkout the master branch
+ 1. [ see doc/upgrade.rst ]
- 9. [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
+ [ENTER HERE FROM CREATING A NEW REPO]
- [FOR NEW REPOSITORIES]
- Check if any patches are needed to make the application work
- on Scripts (ideally, it shouldn't.
+ 9. Push all of your changes in a public place, and encourage others
+ to test, using --srv-path and a full path.
-/- 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.
-
-A mkdir .scripts
-A echo "Deny from all" > .scripts/.htaccess
-
-\---
-
- 10. 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
- 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.
-
- 12. 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
- tests for more information on how to do this.
-
- http://scripts.mit.edu/wizard/testing.html#acceptance-tests
-
- GET APPROVAL BEFORE PROCEEDING ANY FURTHER
+[ XXX: doc/deploy.rst ]
+ 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.
-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
+[ XXX: doc/upgrade.rst ]
* 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.
-
- # the following operation might require -p1
- patch -p0 < ../app-1.2.3/app-1.2.3.patch # [FIDDLY BIT]
-
- * When running updates, if the patch has changed you will have to
+ * When mass producing updates, if the patch has changed you will have to
do a special procedure for your merge:
git checkout pristine
You could also just try your luck with a manual merge using the patch
as your guide.
+[ XXX: doc/layout.rst ]
* 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.
- * .scripts/lock (generated) which locks an autoinstall during upgrade
+ - .scripts/dsn, overriding database source name