X-Git-Url: https://scripts.mit.edu/gitweb/wizard.git/blobdiff_plain/8cda195cdbf9cc5f17c195a7f98167e3e9c4657b..093db3de33bf80917b4b64f18112c6274c91afe3:/TODO diff --git a/TODO b/TODO index 7cf8c5b..adea7d3 100644 --- a/TODO +++ b/TODO @@ -1,52 +1,138 @@ -The Git Autoinstaller - -TODO NOW: - -- 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. +- Make scripts_plugin email heuristic less stupid, or maybe even ask for an + email. This is tracked as Scripts #224 (this issue) and Scripts #193 + (tracking a contact address). +- Current parallelization probably does a bad job distributing + working tasks over different components of the pipeline. Fix + this by adding jitter? Trying to smear things out? + +- Test head doesn't do quite the right thing with version numbers + (shouldn't git describe, instead should give a version infinitely + in the future.) +- Strategy introspection and disabling. +- prepare-config (and others) create .wizard dir even + when not strictly necessary +- Bug out immediately if tags are not present in the master tip + of the repository +- pending doesn't seem to get written out properly sometimes (or + it's being deleted); this makes it hard to --continue on the + event of an upgrade failure. Also, we seem to bounce back to + the production copy to check pending even when we run --continue + from the working dir. +- Newline checks are /really really/ expensive on AFS; see if + we can minimize them or something. Right now, we're testing + a fix where we don't clone with --shared. +- Replace .split("\n") with .splitlines() + +- Need to fix existing repo history? (not adding extra commits; + that'll be more difficult) + + git rebase -i -p --root --onto COMMITID + + This won't work if you need to change the very root of the + repository. You'll probably end up with conflicts and have + to manually resolve everything afterwards. + + But usually you won't need --root --onto unless you really + fucked up the pristine branch. If you just need to change + the scripts spine, + + git rebase -i -p COMMITID + + should work. + +- [SCRIPTS] MediaWiki 1.6.7, 1.9.3 and 1.10.0 + +- geofft comments: + "Connection to scripts.mit.edu closed" is confusing (tracked #393) + the URL should be easier to copy and paste, which means we should + move it out of dialog + We should ... upgrade our autoinstaller + Apparently installing WordPress updates or themes never indicates + completion, and just says "Downloading..", and you have to guess + when it's done + +- [SCRIPTS] phpBB + - phpBB or phpbb? (right now it's the former) + - need an upgrade story; srv needs more versions + - need a story about install/ contrib/ + +- Give users a "certificate" of their merge, which they can + use to reuse that merge commit if something unrelated fails. + +- Human readable quota output +- Nice error message on --continue if you forgot to git add your + resolved file (look for conflict markers) +- The merge interface is a kind of major UI disaster; you won't + be able to use it unless you know how Git works. Also, the + merges can be quite difficult to resolve if upstream has made + large formatting changes like reindenting. We may also consider + providing a --rebase option, which seems to do better when + big problems like this show up. + +- Better mass-* support for just one user (this includes letting + a user mass upgrade just his own autoinstalls) + +- Show progress or something when upgrading +- Allow 'sticky notes' for future upgraders to notice +- .wizard/url semantics are subtly wrong: in particular, if we + explicitly configure a URL at install, we should be able to + detect this URL as baked in from the configuration + +- Rerere support doesn't actually work +- "Version 3.0.0 doesn't exist; did you mean 3.0?" +- Be a little more intelligent when perform web checks; for example, + if we get a forbidden message, that probably means we go the right + address but it's blocked off; if we get a 404 message, that probably + means wrong address. Account Unknown is something particularly good + to check for. +- Wordpress module can do something intelligent if we get redirected + to the installation page. +- wizardResolve* files seem to get left in tmp en-mass, and we don't + know why. + +- [SCRIPTS] Wordpress needs to get rid of the siteurl hack, so that it + actually has a fully-qualified URL http://foo.scripts.mit.edu/blah. + This will also fix Wordpress's cron functionality. We should be + careful not to write over users who are on vhosts. We should figure + out who is still on twiddle paths. We should make sure the redirect + is handled correctly. + +- Remerges aren't reflected in the parent files, so `git diff` output is + spurious. Not sure how to fix this w/o tree hackery. +- Sometimes users remove files. Well, if those files change, they automatically + get marked as conflicted. Maybe we should say for certain files "if they're + gone, they're gone forever"? What is the proper resolution? + +- 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 + +- [SCRIPTS] 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. + +- [SCRIPTS] 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; + namely cooking up the sudo and environment variable lines - 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 + - util.fetch() should use urllib under the hood, not httplib. Code + has to be changed. We should log if we get redirected. - Other stuff - - Make single user mass-migrate work when not logged in as root + - Add support for mypristine workflow + - 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 + - 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 @@ -54,27 +140,17 @@ TODO NOW: - 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: + +- [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. + - Whatever happens here should be used to improve user.email() -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 +[ XXX: metadata.rst ] COMMIT MESSAGE FIELDS: @@ -90,78 +166,19 @@ GIT COMMIT FIELDS: Committer: Real Name Author: lockername locker -NOTES: - -- 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 after - deployment. - OVERALL PLAN: +[ XXX: doc/deps.rst ] * Some parts of the infrastructure will not be touched, although I plan on documenting them. Specifically, we will be keeping: - - parallel-find.pl, and the resulting - /mit/scripts/.htaccess/scripts/sec-tools/store/scriptslist - -* 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) - - 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` + - get-homedirs.sh. which needs to be run as root on scripts. Store + in /mit/scripts/sec-tools/store/scriptslist - X. Commit, with name "Appname x.y.z" - - 4. Checkout the master branch - - 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 - - X. Commit, with name "Appname x.y.z-scripts". This is going to be - amended. - - 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). - - [ENTER HERE FROM CREATING A NEW REPO] - - 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: - - http://scripts.mit.edu/wizard/testing.html#acceptance-tests - - 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) - - 9. Push all of your changes in a public place, and encourage others - to test, using --srv-path and a full path. + - parallel-find.pl, and the resulting + /mit/scripts/sec-tools/store/versions +[ XXX: doc/deploy.rst ] GET APPROVAL BEFORE PROCEEDING ANY FURTHER; THIS IS PUSHING THE CHANGES TO THE PUBLIC @@ -182,34 +199,7 @@ OVERALL PLAN: 12. Run parallel-find.pl to update our inventory -* 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 - do a special procedure for your merge: - - 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 - - You could also just try your luck with a manual merge using the patch - as your guide. - +[ XXX: doc/metadata.rst ] * The repository for a given application will contain the following files: - The actual application's files, as from the official tarball @@ -217,94 +207,5 @@ OVERALL PLAN: - 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. - Inspect the generated configuration files, 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`. - - 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/dsn, overriding database source name