Ideas about migration tests

[chriscool]

If you have ideas about some kind of migration tests we could do, please add them as comments in this issue. Thanks!

[chriscool]

From Kubuxu on IRC:

(19:09:15) Kubuxu: chriscool: in general it would be worth checking if running 0.3.x on 0.4.x does not damage the repos. It might not fit repo-migrations tests but I just thought about it.
(19:09:49) Kubuxu: running 0.3.x on 0.4.x repo, but it might already be tested.

[jbenet]

(preface: i havent looked at the latest tests-- i will later this week.) i think the big thing for fs-repo-migrations testing is making sure everything works fine going up and down without losing any data, including for large repos or repos with large pinsets.

[jbenet]

i wrote up somewhere in an issue or pr (dont recall where) a sample workload (adding lots of stuff, adding pins, removing pins, adding more stuff, gc-ing, applying migrations, etc, all interspersed).

i suspect too that a long-running randomized approach might be helpful in discovering problems.

[chriscool]

@jbenet yeah I will search for what you wrote already

[chriscool]

@jbenet: it's in PR #7. I will extract your ideas and @whyrusleeping's in comments below.

[chriscool]

@whyrusleeping's idea from PR #7:

i'm fine having this tested with or without docker, my main idea for testing this goes something like:

• download ipfs v0.3.10
• init with that binary
• A: generate a set of files that get added and pinned
• B: generate a set of files that get added and unpinned
• C: generate a set of directory trees that get added
• D: generate a set of directory trees that have their subtrees added as well (pin root recursive, and some subtree)
• E: generate some files that have their root directly pinned, and nothing else
• run fs-repo-migration
• download 0.4.0 binary
• verify each of the above

[chriscool]

@jbenet's idea from PR #7:

it may be nice to start with the very first version, and ratchet up all the way, and all the way back down. to ensure all the migrations continue working. :) basically:

(first) for each repo version:

• download a version of go-ipfs corresponding to that repo

for each repo version transition (A->B), both going up and going down:

• (1) ipfs init (with binary known to work with A)
• (2) exercise ipfs repo with lots of data + an involved workload:
  • add lots of files, some large. exercise pinset + gc, pin + unpin various nodes, directly or recursively. get lots of overlap. finish with significant unpinned content (which would go away with a repo gc) and with various recursive pins that overlap
  • https://github.com/jbenet/go-random-files may be useful here
• (3) verify (a) content exists or does not exist in repo as expected, (b) pinset values work as expected (ie the right {recursive, direct, and indirect} pins)
• (4) attempt to use binary known to work with B (should get repo version error)
• (5) migrate repo from A to B (either up, or down)
• (6) verify the same things again. (now with binary known to work with B)

maybe we can start with all that for 2 version transitions:

test transition 2-to-3
test transition 3-to-2

repo version 2 with go-ipfs@0.3.10
repo version 3 with go-ipfs@0.4.0

[chriscool]

So right now we have a number of tests that test transition 2-to-3 and 3-to-2 in:

• t0040-migration-2-3.sh: simple v0.3.10 to v0.4.0-dev and back with a few files
• t0050-migration-2-3-pins.sh: same as previous with pins and gc
• t0060-migration-stress.sh: v0.3.11 to v0.4.0-dev and back with lots of objects and daemon running
• t0070-migration-many.sh: v0.3.7 to v0.3.10 to v0.4.0-dev to v0.3.8 to v0.3.10

Suggestions for more or improved tests?