----- Original Message -----

From: "Jeff Layton" <jlayton@kernel.org>
To: "Frank Filz" <redacted>, "Chuck Lever III" <chuck.lever@oracle.com>, "J. Bruce Fields"
[off-list ref]
Cc: "Dai Ngo" <dai.ngo@oracle.com>, "Linux NFS Mailing List" <redacted>, "Calum Mackay"
[off-list ref]
Sent: Thursday, 23 February, 2023 18:10:47
Subject: Re: [pynfs RFC PATCH] testserver.py: special-case the "all" flag

On Thu, 2023-02-23 at 08:26 -0800, Frank Filz wrote:

quoted

quoted

-----Original Message-----
From: Chuck Lever III [mailto:chuck.lever@oracle.com]
Sent: Thursday, February 23, 2023 8:22 AM
To: Bruce Fields <redacted>
Cc: Jeff Layton <jlayton@kernel.org>; Dai Ngo <dai.ngo@oracle.com>; Linux
NFS Mailing List [off-list ref]; Calum Mackay
[off-list ref]; Frank Filz [off-list ref]
Subject: Re: [pynfs RFC PATCH] testserver.py: special-case the "all" flag

quoted

On Feb 23, 2023, at 10:19 AM, J. Bruce Fields [off-list ref]

wrote:

quoted

quoted

On Wed, Feb 22, 2023 at 01:20:43PM -0500, Jeff Layton wrote:

quoted

The READMEs for v4.0 and v4.1 are inconsistent here. For v4.0, the

"all"

quoted

quoted

quoted

flag is supposed to run all of the "standard" tests. For v4.1 "all"
is documented to run all of the tests, but it actually doesn't since
not every tests has "all" in its FLAGS: field.

I move that we change this. If I say that I want to run "all", then I
really do want to run _all_ of the tests. Ensure that every test has
the "all" flag set.

In some (all?) cases where the "all" flag was left off, it was
intentional.

We try not to flag spec-compliant servers as failing, because people
are sometimes a little careless about "fixing" failures that in their
particular case really shouldn't be fixed.  But sometimes it's still
useful to have a test that goes somewhat beyond the spec.

There might be other ways to handle that kind of test, but it would
need some more thought.

We could use a different name for "all" since it doesn't actually run

/all/ tests.

quoted

Jeff suggested "standard", which seems sensible.

The challenge with changing this is all the CI scripts and other testing
scripts out there that use all. If all suddenly changed, server maintainers
might get a deluge of bug reports for failing odd test cases no one
necessarily expected to work...

Are those CI systems pulling down the upstream tree to run? How do they
contend with new tests that might suddenly show up as part of "all"?

We are actually explicitly disabling some tests that are part of the `all`

./testserver.py -v --noinit --xml=/scratch/jenkins/root/workspace/pynfs-test/xunit-report-v40.xml nfs-lab:/data/nfs all noACC2a noACC2b noACC2c noACC2d noACC2f noACC2r noACC2s noCID1 noCID2 noCID4a noCID4b noCID4c noCID4d noCID4e noCLOSE10 noCLOSE12 noCLOSE5 noCLOSE6 noCLOSE8 noCLOSE9 noCMT1aa noCMT1b noCMT1c noCMT1d noCMT1e noCMT1f noCMT2a noCMT2b noCMT2c noCMT2d noCMT2f noCMT2s noCMT3 noCMT4 noCR12 noLKT1 noLKT2a noLKT2b noLKT2c noLKT2d noLKT2f noLKT2s noLKT3 noLKT4 noLKT6 noLKT7 noLKT8 noLKT9 noLKU10 noLKU3 noLKU4 noLKU5 noLKU6 noLKU6b noLKU7 noLKU8 noLKU9 noLKUNONE noLOCK12a noLOCK12b noLOCK13 noLOCK24 noLOCKRNG noLOCKCHGU noLOCKCHGD noOPCF1 noOPCF6 noOPDG2 noOPDG3 noOPDG6 noOPDG7 noOPEN15 noOPEN18 noOPEN2 noOPEN20 noOPEN22 noOPEN23 noOPEN24 noOPEN26 noOPEN27 noOPEN28 noOPEN3 noOPEN30 noOPEN4 noRENEW3 noRD1 noRD10 noRD2 noRD3 noRD5 noRD6 noRD7a noRD7b noRD7c noRD7d noRD7f noRD7s noRPLY1 noRPLY10 noRPLY12 noRPLY14 noRPLY2 noRPLY3 noRPLY5 noRPLY6 noRPLY7 noRPLY8 noRPLY9 noSATT3d noSATT4 noSATT6d noSATT6r noSATT18 noSEC7 noWRT1 noWRT11 noWRT13 noWRT14 noWRT15 noWRT18 noWRT19 noWRT1b noWRT2 noWRT3 noWRT6a noWRT6b noWRT6c noWRT6d noWRT6f noWRT6s noWRT8 noWRT9

However, I don't think it will be a big issue to adjust if suddenly `all` has more tests.
BTW, we have the containerized version as well, which is publicly available. I will write some docu...

podman run -ti --rm -v `pwd`/out:/out dcache/pynfs:0.1  /bin/bash -c "cd /pynfs/nfs4.0; python3 -u ./testserver.py --xml=/out/xunit-report-v40.xml --noinit nfs-lab:/data all; exit 0"

I am happy to share Dockerfile and make it more user friendly :)

Best regards,
   Tigran.

quoted

quoted

Also, we could add test categories specifically for particular server
implementations, if that's interesting to folks.

I have already done so with a ganesha tag...

Literally all anyone has to do is start using a new tag so it's a trivial
thing for developers to add.

The problem is that you have to add the tag to hundreds of tests. It's
scriptable, sure, but if you want to be at all selective, it's not
trivial.

That said, I'm open to doing something different here. Maybe we could
declare a new "everything" special case instead? It's confusing naming,
but that would at least preserve the existing behavior for those CI
systems.

quoted

quoted

quoted

--b.

quoted

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
nfs4.1/testmod.py | 2 ++
1 file changed, 2 insertions(+)

If this is unacceptable, then an alternative could be to add a new
(similarly special-cased) "everything" flag.

diff --git a/nfs4.1/testmod.py b/nfs4.1/testmod.py index

11e759d673fd..7b3bac543084 100644

--- a/nfs4.1/testmod.py
+++ b/nfs4.1/testmod.py

@@ -386,6 +386,8 @@ def createtests(testdir):
    for t in tests:

##         if not t.flags_list:
##             raise RuntimeError("%s has no flags" % t.fullname)
+        if "all" not in t.flags_list:
+            t.flags_list.append("all")
        for f in t.flags_list:
            if f not in flag_dict:
                flag_dict[f] = bit
--
2.39.2

--
Chuck Lever

--
Jeff Layton [off-list ref]