-- Bugs
- - Exception parsing doesn't work when HTML pages or other complex
- output is returned, which results in hilarious mass error messages.
- Check logs for 0324 for a relevant example.
- - git pull, when it fails, has a lot of ^M characters; these should
- be removed
-
-- Make it faster
- - Wipe temp directories if the upgrade succeeds
- - Put temp directories on tmpfs before merging, then move to disk
- if it fails and needs resolution. /var/run is a pretty good
- choice if your running as root, not so good if you're not. Find
- other common tmpfs locations (mount | grep tmpfs) and perhaps
- check some common ones.
- - 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).
+- --retry option for install, so it won't complain about a directory already
+ being there.
+- The calling web code invocations are a mess, with stubs living
+ in the install, deploy modules and the real deal living in util. Furthermore,
+ we use the scripts-specific heuristic to determine where the app
+ lives, and the only reason my test scripts work is because they
+ get manually fed the domain and path by my environment variables.
+
+ We will record the URL used for the initial installation, and save it in
+ .scripts/url. If autodetection in either direction is
+ available, we verify this value against the actual file path the installation
+ lives in (for the scripts case, we can do a file-level comparison because we
+ know the web root of any given file). If they mismatch, we error out
+ and have someone manually resolve the problem. If autodetection is not
+ available, we use the saved .scripts/url for operations.
+
+- wizard install wordpress should ask for password
+- Test code should auto-nuke the database using `wizard remove` before doing a new install
+- git diff :1:$file :2:$file to find out what the user did, or is it :3:?
+- Document how to fix a broken upgrade
+- php.ini needs to get substituted!
+- 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
+- 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)