X-Git-Url: https://scripts.mit.edu/gitweb/wizard.git/blobdiff_plain/81ca5fd526fdb579d478ba741ea6ceb7c349265a..6617b37f3e19b1d97292f6a28b39c5b8b696f427:/TODO diff --git a/TODO b/TODO index ec10358..9cb904a 100644 --- a/TODO +++ b/TODO @@ -2,39 +2,36 @@ The Git Autoinstaller TODO NOW: -- 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 -- Indicate a default is available in the --help message. - -- 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). +- XXX: Upgrades don't pull updated tags, breaking git describe --tags! + Fix this for the future, and figure out how to make everyone else happy! +- XXX: Some installs are throwing spurious errors; investigate +- XXX: Prolly would be nice to have some information about how many installs actually succeeded +- 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.) 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. + 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 @@ -44,19 +41,24 @@ TODO NOW: 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. + 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 + - 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 @@ -126,54 +128,16 @@ OVERALL 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. - - 2. Checkout the pristine branch - - 3. Run wizard `prepare-pristine APP-VERSION` - - 4. Checkout the master branch - - 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 - - [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. - - 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. + 1. [ see doc/upgrade.rst ] - 6. Check if there are any special update procedures, and update - the wizard.app.APPNAME module accordingly (or create it, if - need be). + [ENTER HERE FROM CREATING A NEW REPO] - 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. + 9. Push all of your changes in a public place, and encourage others + to test, using --srv-path and a full path. - 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 - - 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 - - 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 @@ -192,15 +156,10 @@ OVERALL PLAN: 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 @@ -220,6 +179,7 @@ OVERALL PLAN: 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 @@ -227,3 +187,5 @@ OVERALL PLAN: - A .scripts directory, with the intent of holding Scripts specific files if they become necessary. + - .scripts/dsn, overriding database source name +