Description of problem: tests/bugs/bug-861542.t is failing in Rackspace, due to the VMs there having long hostnames, which the test isn't able to cope with. # tests/bugs/bug-861542.t 1..13 ok 1 ok 2 No volumes present ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 not ok 10 Got "" instead of "N/A" ok 11 ok 12 ok 13 The failing piece of code in the test is this: EXPECT "N/A" port_field $V0 '0'; # volume status It's expecting output similar to this (which EXPECT then processes): # gluster volume status patchy Status of volume: patchy Gluster process Port Online Pid ----------------------------------------------------------------- Brick somename:/d/backends/brick0 N/A N N/A NFS Server on localhost 2049 Y 31805 When a hostname is fairly long though, the output from "gluster volume status $V0" wraps around to the next line, so the EXPECT statement doesn't receive the value. # gluster volume status patchy Status of volume: patchy Gluster process Port Online Pid ----------------------------------------------------------------- Brick jc-api-test-node0.cloud.gluster.org:/d/backends/b rick0 N/A N N/A NFS Server on localhost 2049 Y 31805 I'm not sure of the correct way to fix this. The tests/bugs/bug-861542.t already has an --xml version of the failing list in it (which passes). Dropping the non --xml line doesn't seem correct though. Perhaps if we can find a way for EXPECT to not fail on long hostnames? Version-Release number of selected component (if applicable): Upstream GlusterFS git master, as of Thu 3rd April 2014. commit 997c89b6172116557f981510a94232486ec526b0 How reproducible: Every time
s/failing list in it/ failing test in it/ *sigh*
Thinking about this more, it probably makes sense to adjust the GlusterFS CLI, so that "--mode=script" doesn't wrap. Having wrapping enabled just doesn't seem like a good idea for script processing in general.
"tests" component is for tests framework only. File a bug under test component if you find a bug in 1. any of the *.rc files under tests/ 2. run-tests.sh For everything else, the bug should be filed on 1. component which is being tested by .t file if the .t file requires fix. 2. component which is causing a valid .t file to fail in regression. I have used my best judgement here to move the bug to right component. In case of ambiguity, I have placed the blame on the .t file component. Please consider test bugs under the same backlog list that tracks other bugs in your component.
This bug is getting closed because the 3.5 is marked End-Of-Life. There will be no further updates to this version. Please open a new bug against a version that still receives bugfixes if you are still facing this issue in a more current release.