1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
#
# Things to do for testing
#
* ensure user is root? -- easy to do
* have tests create their own target using targetcli and
a file? -- this would be much better, but would pull
in a requirement for targetcli-fb and friends, plus we
would still need a place for a decent-sized (1G?) file.
* have tests do discovery themselves, instead of requiring
that to be done already. Either way, we may still need
to know the IQN of our target and the host where it lives.
* Have tests figure out the device path, so it doesn't have
to be passed in. Passing it in requires the called to
login to the remote iscsi target and look at the path
in /dev/disk/by-id (for example). If we created the
disk, we might have a better chance of guessing its name?
* Augment tests
Right now, the test is a long-ass regression test. Very
repetitive and time-consuming. But we also have need of
regular unit tests, e.g. for functionality, where a new
test could be added each time we find a bug? New tests
could include things like:
- multipathing
- using interface files or not
- discovery, with and without authentication
- session creation, w/ & w/o auth
* Gather actual regression data!
- Since we are testing all of these combinations, why not
keep historical data to see if there are any negative
trends (i.e. regressions)? Need to understand fio and bonnie++
output better to find a way to gather one or two datapoints
(max) per test, out of all the info dumped by these
programs.
* Add in test cases for Discovery and/or Connection validation,
which would require either a separate target set up for that,
or control of our own target
* Only allow /dev/disk/by-* paths, as /dev/sd? paths are
inherently problematic, since they can change names.
* Add back in the "big warning" from regression.sh?
* Find a faster way to zero the disc than using sgdisk and
dd. Running both of these on a 10G disc can take minutes.
* Come up with some common subsets of tests that can be run
when needed, since running all the tests takes forever. Maybe
a "short", "medium", and "long" option, so the caller doesn't
have to remember the arcane command-line options?
|
