|
From: Reid P. <rei...@gm...> - 2009-09-22 21:11:55
|
Hi Tatsuya, Sorry for the last-minute feedback, I neglected to sign up for the dev list. Some things I've come up against or recalled as I type this follow. Setup It is not very straightforward. At least on a debian (lenny) box, I have to execute 25 commands (counting 3 seds in place of manual edits) to get to the point where I can attempt to run a test. I'm also not the biggest fan of the setup/teardown, but I have no helpful suggestions for something better that maintains the same level of overhead. I was able to find all the documentation, eventually, but it seemed like that could be streamlined as well, I often have to follow a doc trail over 3+ files or into source to figure out what is going on. Debugging I didn't find it that hard to only run a few tests, once you know where to comment out things, but a abort-on-first-failure would certainly be useful. Overall it was cumbersome. I found that the non-verbose debugging was too little, and the verbose was too much, some gradient might be nice, I usually found myself just running tcpdump or wireshark on all the interfaces. Features that would be nice Like Yiannis/Brandon, I wouldn't mind if the framework was python (over perl), even if it is unlikely that perl is the necessary and sufficient cause here. Structure/organization weren't necessarily intuitive for me, as a casual debugger, we would get that as a side-effect of a stricter language. If you are considering a complete rewrite it might be nice if there were additional options for larger/smaller scale tests, instead of the static configuration of 4 ports. This may be my inexperience, but I wasn't aware of any way of (for example) testing a 2-3 port physical openflow switch, or wifi. -Reid |