LGTM and it fixes the tests for UFS, though I'm not an expert in this area. The problem with fusefs has a different cause; I'll discuss on bugzilla.

In D38130#866489, @mav wrote:

I suppose that request would give you all traffic of the LUNs accessible through that target, even one going though different targets. As alternative, CTL collects per-port statistics, that would closer match targets, if desired, but then without separation between different LUNs.

@mav I think reporting a schema like this would work . I need to prototype it first to be sure, though:

Note that ctlstat's prometheus functionality has already been MFCed to stable/13. However, it wasn't included in 13.1. So there's still time to change the output schema if we must, without breaking compatibility with any releases.

In D38130#866209, @mav wrote:

I've never before looked on this code, but all this targdata.targets[lun] logic looks wrong to me. Any LUN may be mapped into multiple different ports, think that this code does not allow. LUNs not mapped into any port is only a one minor case of generally broken design. I have no idea what data this Prometheus is expecting to receive, but right now it obviously does not receive the full picture. This particular patch is not bad, but it just does not fix whole problem, only a minor part.

This looks like a good start. I'm not a fan of the methodize stuff, though. I think it makes the tests harder to read and harder to search. Is there a way to parameterize the tests without using methodize, even if it becomes slightly more verbose?

Seems reasonable to me.

In D37971#863583, @ngie wrote:

I hate to be a wet blanket, but a lot of the code seems to go against design decisions made in pytest around fixtures, extendability, etc.
In particular, just glancing at this commit, it seems to rely on J-Unit-like structure (used in unittest), which is not strictly adhered to in pytest.
FWIW, I honestly think integration should be the other way around: ATF should integrate into pytest, not pytest should integrate into ATF. If things were done in that manner and we used the JUnit output format (supported natively in pytest), we could move away from Kyua to a framework that is less bespoke, has a ton less boilerplate than ATF, has better developer and user experience, and has better opensource mindshare than ATF/Kyua.
The main value ATF/Kyua provides (IMHO) is the ability to integrate in tests from NetBSD and a format to express legacy tests in, which gave FreeBSD a great head start in terms of CI/testability. Other than that, it's kind of a kludgy framework.

LGTM. It looks like I included sys/systm.h because an earlier, pre-phabricator version of the change included a panic() within cmp_sysctl_oid, but then I forgot to revert the header change.

In D37873#861872, @jhb wrote:

Is this related to the issues you had with using if_wg(4) interfaces in jails?

Since the test is no longer vnet-specific, don't forget to adjust the commit message. Also, does the polling loop still exhibit problems with the non-vnet version of the test? We've got to get rid of that "sleep 5".

I find this confusing. It's weird that Kyua handles some of the test case isolation, and Python handles other parts. It also means that an unprivileged user won't be able to simply type "kyua test ..." and expect the unprivileged test cases to work. It seems like either the vnet stuff needs to be moved up into Kyua itself, or the privilege dropping needs to be moved down out of the runner and into the test class. In the latter case, the test case would still have a "require.user root", but could use some other decorator or just the class setup to drop privileges.

A "test_case_cleanup" method would work. But it would be more Pythonic if it were a teardown method. Would that be possible?

Ahh, you're correct about the cleanup directory. I misremembered that.

This looks great. I especially like the ability to parameterize test cases, which isn't easy with atf-sh-api or atf-c-api. What about cleanup? I think atf-python tests need to do that differently, right? It would be good to add an example for that.

The only problem I have with this new feature is that it is 75% redundant with updatesready. I think that having two so-similar features will confuse users. Is there any way to get the benefits of both, while not adding any new commands?

I think this looks really great. I assume you have a few extra test cases that you're planning to add to ping_test.sh? Personally, I don't have strong opinions about whether to use atf-sh or pytest, as long as you can get the cleanup and metadata correct. And don't forget that you'll need to add injection.py to ObsoleteFiles.mk, or else rename pinger.py to injection.py.

I can't reproduce markj's problem about dbind, whether I run on a system with or without X . I'm going to guess that it's something about his particular environment. I'll fix the braces and commit.

• Also replace if_clone_detach with ifc_detach_cloner

@jhb @kevans you're right, this change isn't necessary to do what I said. I think I got confused by two other problems:

• The jail can't load the if_wg kernel module, and
• https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264981

Is there any value to this change anyway, as an act of maintenance? Or should I just abandon it?

I see. Can you suggest better wording, or should I just abandon it and assume that users will figure it out?

@markj @jlduran_gmail.com I fixed the network errors that markj found. A necessary side effect seems to be the pep-8 style warnings, and I don't see any way to suppress those. Are there any other problems here?

Thanks for the review. As you probably figured out, it needs llvm90 regardless of the system compiler, because it needs libclang.

Ok, I committed it. Next I'll fix sysutils/nfs_exporter to run as non-root too.

• Add missing file
• Match ping's stdout in the injection tests.
• Python style
• More specific output checking for inject_pip
• fixup:

In D37210#853886, @markj wrote:

One problem I noticed is that the tests can spuriously fail with some error messages from scapy:

markj@nuc> sudo kyua debug ping_test:inject_opts
Executing command [ python3 /usr/tests/sbin/ping/injection.py opts ]
Fail: stderr not empty
--- /dev/null   2022-11-30 14:43:29.782039000 +0000
+++ /tmp/kyua.FOws6H/2/work/check.VgUqKM/stderr 2022-11-30 14:43:27.574257000 +0000
@@ -0,0 +1,5 @@
+
+(injection.py:37468): dbind-WARNING **: 14:43:27.258: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/kyua.y0IpE0/7/work/.cache/at-spi/bus_0: No such file or directory
+WARNING: No IPv4 address found on bridge0 !
+WARNING: No IPv4 address found on epair0a !
+WARNING: more No IPv4 address found on epair0b !
Files left in work directory after failure: .cache, .config, tun.txt
ping_test:inject_opts  ->  failed: atf-check failed; see the output of the test for details

@thj the fix is in main now. Could you please review again?

In D37519#853759, @rmacklem wrote:

• The sysctl falls out of the krpc code. I don't know why dfr@ provided it. Maybe for old NFS code or some other protocol that uses the krpc. --> If you set it after starting the nfsd, it would override the command line setting, I think. Basically the sysctls are useless for the new nfsd code, but to get rid of them, the krpc would need to be changed to never generate them.

I don't know much about the NFS server code, but I've got a few questions:

@jlduran_gmail.com don't get too invested; @thj already has a fix prepared.

@thj are we ready to commit?

Well, it isn't ideal. But it's certainly much better than it used to be, and the ZFS tests are much too big to shoot for "ideal".

• Perform the check earlier

In D37313#847880, @markj wrote:

Seems ok, but why not handle it in g_label_taste(), or even at some higher level in GEOM (maybe g_disk_create())? I can't think of any classes that will do something sane with a provider with sectorsize 0...

In D37309#847728, @mav wrote:

Not that I have specific objections against this, but I think it would be much better to implement a generic way to print all consumers connected to specified GEOM provider. This code does not look anyhow specific to gmultipath.