Bug 1564078
Summary: | [Ganesha]Pynfs WRT5b (st_write.testTooLargeData) test case is failing | ||
---|---|---|---|
Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Manisha Saini <msaini> |
Component: | nfs-ganesha | Assignee: | Kaleb KEITHLEY <kkeithle> |
Status: | CLOSED NOTABUG | QA Contact: | Manisha Saini <msaini> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | rhgs-3.4 | CC: | amukherj, bfields, dang, ffilz, grajoria, jthottan, pasik, rhs-bugs, storage-qa-internal |
Target Milestone: | --- | Keywords: | ZStream |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-11-19 10:35:04 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
Manisha Saini
2018-04-05 10:03:06 UTC
This test is a new test that expects the server to not process an overly large request and only expects the server to not crash. I will check with Bruce Fields Oops, that comment went out before I was done... I added Bruce Fields, our older ntirpc chokes on the overly large request (upstream with newer ntirpc passes this test case), maybe we can add this failure mode as acceptable. In any case, the failure of this test is not an issue, if we can't change the test, we can just accept this as an expected failure. (In reply to Frank Filz from comment #4) > Oops, that comment went out before I was done... > > I added Bruce Fields, our older ntirpc chokes on the overly large request > (upstream with newer ntirpc passes this test case), maybe we can add this > failure mode as acceptable. > > In any case, the failure of this test is not an issue, if we can't change > the test, we can just accept this as an expected failure. This is a new test added in pynfs test suit which is failing for earlier released RHGS versions as well and is not a regression. As discussed in nfs scrum and as mentioned in comment#4 by Frank,the failure is is not causing any functionality impact from application point of view.We can live with this in RHGS 3.4. This is just a bug in the pynfs test, it should succeed unconditionally. The "except:" should probably be catching a larger set of exceptions. (How exactly is it failing in your case?) So I guess RPC-level errors raise exceptions instead of returning errors. I think this will allow pretty much anything, maybe that's what we should do: diff --git a/nfs4.0/servertests/st_write.py b/nfs4.0/servertests/st_write.py index b5ad291f2cba..036ccec1a5c7 100644 --- a/nfs4.0/servertests/st_write.py +++ b/nfs4.0/servertests/st_write.py @@ -171,7 +171,7 @@ def testTooLargeData(t, env): # We don't care much what the server does, this is just a check # to make sure it doesn't crash. res = c.write_file(fh, data, 0, stateid) - except IOError: + except: # Linux knfsd closes the socket when the write is too large. # That's OK. pass (In reply to J. Bruce Fields from comment #8) > So I guess RPC-level errors raise exceptions instead of returning errors. I > think this will allow pretty much anything, maybe that's what we should do: > > diff --git a/nfs4.0/servertests/st_write.py b/nfs4.0/servertests/st_write.py > index b5ad291f2cba..036ccec1a5c7 100644 > --- a/nfs4.0/servertests/st_write.py > +++ b/nfs4.0/servertests/st_write.py > @@ -171,7 +171,7 @@ def testTooLargeData(t, env): > # We don't care much what the server does, this is just a check > # to make sure it doesn't crash. > res = c.write_file(fh, data, 0, stateid) > - except IOError: > + except: > # Linux knfsd closes the socket when the write is too large. > # That's OK. > pass Yea, that sounds good. The only purpose of this test case is to poke the server with something horrible and make sure it doesn't crash. Hmm, will this detect if a server lies and says the write succeeded? (In reply to Frank Filz from comment #9) > Yea, that sounds good. The only purpose of this test case is to poke the > server with something horrible and make sure it doesn't crash. OK, I've pushed out that pynfs change. This bug can be closed with NOTABUG. > Hmm, will this detect if a server lies and says the write succeeded? I don't think it's worth it to check for that particular case. It would be easy just to fail on a write that returns success, but on its own I'm not sure whether that's actually a server bug. |