Bug 1084175

Summary: tests/bugs/bug-861542.t needs to be more robust. It's failing on long hostnames.
Product: [Community] GlusterFS Reporter: Justin Clift <jclift>
Component: cliAssignee: Krutika Dhananjay <kdhananj>
Status: CLOSED EOL QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: bugs, kwade, rtalur
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-17 15:56:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Justin Clift 2014-04-03 18:27:10 UTC
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

Comment 1 Justin Clift 2014-04-03 18:28:50 UTC
s/failing list in it/ failing test in it/

*sigh*

Comment 2 Justin Clift 2014-04-08 16:05:31 UTC
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.

Comment 4 Raghavendra Talur 2016-03-08 19:47:41 UTC
"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.

Comment 5 Niels de Vos 2016-06-17 15:56:26 UTC
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.