[LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Sebastian Chlad]

nfs_lib.sh checked key server_side prerequisites on the system under test.
In 2_host setup this incorrectly required server_side tools on lhost.
This patch keep netns behavior unchanged, but in true 2-host mode run
server-side checks on rhost via tst_rhost_run().

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
---
 testcases/network/nfs/nfs_stress/nfs_lib.sh | 22 +++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/testcases/network/nfs/nfs_stress/nfs_lib.sh b/testcases/network/nfs/nfs_stress/nfs_lib.sh
index 1ac8bd657..e52f96a5a 100644
--- a/testcases/network/nfs/nfs_stress/nfs_lib.sh
+++ b/testcases/network/nfs/nfs_stress/nfs_lib.sh
@@ -45,7 +45,7 @@ TST_SKIP_FILESYSTEMS="exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
 TST_MOUNT_DEVICE=1
 TST_FORMAT_DEVICE=1
 TST_NEEDS_ROOT=1
-TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount exportfs mount.nfs"
+TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount mount.nfs"
 TST_SETUP="${TST_SETUP:-nfs_setup}"
 TST_CLEANUP="${TST_CLEANUP:-nfs_cleanup}"
 TST_NEEDS_DRIVERS="nfsd"
@@ -186,10 +186,24 @@ nfs_setup()
 		tst_brk TCONF "Cannot run nfs-stress test on mounted NFS"
 	fi
 
+	if tst_net_use_netns; then
+		tst_cmd_available exportfs || tst_brk TCONF "'exportfs' not found"
+	else
+		tst_rhost_run -c "command -v exportfs >/dev/null" || tst_brk TCONF "'exportfs' not found on rhost"
+	fi
+
 	if tst_cmd_available pgrep; then
-		for i in rpc.mountd rpc.statd; do
-			pgrep $i > /dev/null || tst_brk TCONF "$i not running"
-		done
+		if tst_net_use_netns; then
+			tst_res TINFO "checking rpc.mountd/rpc.statd on lhost (netns mode)"
+			for i in rpc.mountd rpc.statd; do
+				pgrep $i > /dev/null || tst_brk TCONF "$i not running"
+			done
+		else
+			tst_res TINFO "checking rpc.mountd/rpc.statd on rhost (2-host mode)"
+			for i in rpc.mountd rpc.statd; do
+				tst_rhost_run -c "pgrep $i > /dev/null" || tst_brk TCONF "$i not running on rhost"
+			done
+		fi
 	fi
 
 	tst_res TINFO "$(mount.nfs -V)"
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Petr Vorel]

Hi Sebastian,

[ Cc Martin and Cyril ]

> nfs_lib.sh checked key server_side prerequisites on the system under test.
> In 2_host setup this incorrectly required server_side tools on lhost.
> This patch keep netns behavior unchanged, but in true 2-host mode run
> server-side checks on rhost via tst_rhost_run().

First, thank you for fixing 2 host side setup.

> Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
> ---
>  testcases/network/nfs/nfs_stress/nfs_lib.sh | 22 +++++++++++++++++----
>  1 file changed, 18 insertions(+), 4 deletions(-)

> diff --git a/testcases/network/nfs/nfs_stress/nfs_lib.sh b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> index 1ac8bd657..e52f96a5a 100644
> --- a/testcases/network/nfs/nfs_stress/nfs_lib.sh
> +++ b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> @@ -45,7 +45,7 @@ TST_SKIP_FILESYSTEMS="exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
>  TST_MOUNT_DEVICE=1
>  TST_FORMAT_DEVICE=1
>  TST_NEEDS_ROOT=1
> -TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount exportfs mount.nfs"
> +TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount mount.nfs"

>  TST_SETUP="${TST_SETUP:-nfs_setup}"
>  TST_CLEANUP="${TST_CLEANUP:-nfs_cleanup}"
>  TST_NEEDS_DRIVERS="nfsd"
> @@ -186,10 +186,24 @@ nfs_setup()
>  		tst_brk TCONF "Cannot run nfs-stress test on mounted NFS"
>  	fi

> +	if tst_net_use_netns; then
> +		tst_cmd_available exportfs || tst_brk TCONF "'exportfs' not found"
You would here use tst_require_cmds exportfs, but ...

> +	else
> +		tst_rhost_run -c "command -v exportfs >/dev/null" || tst_brk TCONF "'exportfs' not found on rhost"
> +	fi

... if you remove exportfs from TST_NEEDS_CMDS you can use the same code for
both netns and 2 based setup (tst_rhost_run should work well on netns).

I was thinking about having a special variable for checking rhost only, but
given that tst_test.sh is now also deprecated, we will have to solve this in
shell loader.

> +
>  	if tst_cmd_available pgrep; then
> -		for i in rpc.mountd rpc.statd; do
> -			pgrep $i > /dev/null || tst_brk TCONF "$i not running"
> -		done
> +		if tst_net_use_netns; then
> +			tst_res TINFO "checking rpc.mountd/rpc.statd on lhost (netns mode)"
> +			for i in rpc.mountd rpc.statd; do
> +				pgrep $i > /dev/null || tst_brk TCONF "$i not running"
> +			done
> +		else
> +			tst_res TINFO "checking rpc.mountd/rpc.statd on rhost (2-host mode)"
> +			for i in rpc.mountd rpc.statd; do
> +				tst_rhost_run -c "pgrep $i > /dev/null" || tst_brk TCONF "$i not running on rhost"
> +			done
> +		fi

And here of course as well use tst_rhost_run for both.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Sebastian Chlad]

On Sun, 22 Feb 2026 at 21:34, Petr Vorel <pvorel@suse.cz> wrote:

> Hi Sebastian,
>
> [ Cc Martin and Cyril ]
>
> > nfs_lib.sh checked key server_side prerequisites on the system under
> test.
> > In 2_host setup this incorrectly required server_side tools on lhost.
> > This patch keep netns behavior unchanged, but in true 2-host mode run
> > server-side checks on rhost via tst_rhost_run().
>
> First, thank you for fixing 2 host side setup.
>
> > Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
> > ---
> >  testcases/network/nfs/nfs_stress/nfs_lib.sh | 22 +++++++++++++++++----
> >  1 file changed, 18 insertions(+), 4 deletions(-)
>
> > diff --git a/testcases/network/nfs/nfs_stress/nfs_lib.sh
> b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > index 1ac8bd657..e52f96a5a 100644
> > --- a/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > +++ b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > @@ -45,7 +45,7 @@
> TST_SKIP_FILESYSTEMS="exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
> >  TST_MOUNT_DEVICE=1
> >  TST_FORMAT_DEVICE=1
> >  TST_NEEDS_ROOT=1
> > -TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount exportfs mount.nfs"
> > +TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount mount.nfs"
>
> >  TST_SETUP="${TST_SETUP:-nfs_setup}"
> >  TST_CLEANUP="${TST_CLEANUP:-nfs_cleanup}"
> >  TST_NEEDS_DRIVERS="nfsd"
> > @@ -186,10 +186,24 @@ nfs_setup()
> >               tst_brk TCONF "Cannot run nfs-stress test on mounted NFS"
> >       fi
>
> > +     if tst_net_use_netns; then
> > +             tst_cmd_available exportfs || tst_brk TCONF "'exportfs'
> not found"
> You would here use tst_require_cmds exportfs, but ...
>
> > +     else
> > +             tst_rhost_run -c "command -v exportfs >/dev/null" ||
> tst_brk TCONF "'exportfs' not found on rhost"
> > +     fi
>
> ... if you remove exportfs from TST_NEEDS_CMDS you can use the same code
> for
> both netns and 2 based setup (tst_rhost_run should work well on netns).
>

good point. I have tested v2 which I will send shortly.



>
> I was thinking about having a special variable for checking rhost only, but
> given that tst_test.sh is now also deprecated, we will have to solve this
> in
> shell loader.
>

I was also thinking about it but in the end I think it could be just yet
another variable to control the test flow, so one more thing
to worry about... and as far as I see relying on the presence of already
defined variables seems good enough.



>
> > +
> >       if tst_cmd_available pgrep; then
> > -             for i in rpc.mountd rpc.statd; do
> > -                     pgrep $i > /dev/null || tst_brk TCONF "$i not
> running"
> > -             done
> > +             if tst_net_use_netns; then
> > +                     tst_res TINFO "checking rpc.mountd/rpc.statd on
> lhost (netns mode)"
> > +                     for i in rpc.mountd rpc.statd; do
> > +                             pgrep $i > /dev/null || tst_brk TCONF "$i
> not running"
> > +                     done
> > +             else
> > +                     tst_res TINFO "checking rpc.mountd/rpc.statd on
> rhost (2-host mode)"
> > +                     for i in rpc.mountd rpc.statd; do
> > +                             tst_rhost_run -c "pgrep $i > /dev/null" ||
> tst_brk TCONF "$i not running on rhost"
> > +                     done
> > +             fi
>
> And here of course as well use tst_rhost_run for both.
>
> Kind regards,
> Petr
>

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH v2] nfs: Adapt the lib to allow to test in 2-host mode

[Sebastian Chlad]

nfs_lib.sh checked key server_side prerequisites on the system under test.
In 2_host setup this incorrectly required server_side tools on lhost.

Switch exportfs and rpc.mountd/rpc.statd checks in nfs_setup() to
tst_rhost_run(). This aligns netns and 2-host handling in one path and
keeps 2-host checks on rhost.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
---
 testcases/network/nfs/nfs_stress/nfs_lib.sh | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/testcases/network/nfs/nfs_stress/nfs_lib.sh b/testcases/network/nfs/nfs_stress/nfs_lib.sh
index 1ac8bd657..8bff3f23a 100644
--- a/testcases/network/nfs/nfs_stress/nfs_lib.sh
+++ b/testcases/network/nfs/nfs_stress/nfs_lib.sh
@@ -45,7 +45,7 @@ TST_SKIP_FILESYSTEMS="exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
 TST_MOUNT_DEVICE=1
 TST_FORMAT_DEVICE=1
 TST_NEEDS_ROOT=1
-TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount exportfs mount.nfs"
+TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount mount.nfs"
 TST_SETUP="${TST_SETUP:-nfs_setup}"
 TST_CLEANUP="${TST_CLEANUP:-nfs_cleanup}"
 TST_NEEDS_DRIVERS="nfsd"
@@ -186,9 +186,13 @@ nfs_setup()
 		tst_brk TCONF "Cannot run nfs-stress test on mounted NFS"
 	fi
 
-	if tst_cmd_available pgrep; then
+	tst_rhost_run -c "command -v exportfs >/dev/null" ||
+		tst_brk TCONF "'exportfs' not found on rhost"
+
+	if tst_rhost_run -c "command -v pgrep >/dev/null"; then
+		tst_res TINFO "checking rpc.mountd/rpc.statd on rhost"
 		for i in rpc.mountd rpc.statd; do
-			pgrep $i > /dev/null || tst_brk TCONF "$i not running"
+			tst_rhost_run -c "pgrep $i > /dev/null" || tst_brk TCONF "$i not running on rhost"
 		done
 	fi
 
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Petr Vorel]

Hi Sebastian,

...
> > ... if you remove exportfs from TST_NEEDS_CMDS you can use the same code
> > for
> > both netns and 2 based setup (tst_rhost_run should work well on netns).


> good point. I have tested v2 which I will send shortly.

+1

> > I was thinking about having a special variable for checking rhost only, but
> > given that tst_test.sh is now also deprecated, we will have to solve this
> > in
> > shell loader.

> I was also thinking about it but in the end I think it could be just yet
> another variable to control the test flow, so one more thing
> to worry about... and as far as I see relying on the presence of already
> defined variables seems good enough.

Until shell loader came I thought we'd parse tests which use tst_test.sh
(I thought therefore these variables would be used in metadata).

Now I'm thinking whether write the minimal tst_net.sh functionality directly in C
as either new library (code in libs/) or just core library extension (lib/*.c).
For sure it'd be quicker just to put subset of required code into new script,
but it's worth to consider it. That would also help rewrite tests in C in the
future.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Cyril Hrubis]

Hi!
> > Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
> > ---
> >  testcases/network/nfs/nfs_stress/nfs_lib.sh | 22 +++++++++++++++++----
> >  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> > diff --git a/testcases/network/nfs/nfs_stress/nfs_lib.sh b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > index 1ac8bd657..e52f96a5a 100644
> > --- a/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > +++ b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > @@ -45,7 +45,7 @@ TST_SKIP_FILESYSTEMS="exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
> >  TST_MOUNT_DEVICE=1
> >  TST_FORMAT_DEVICE=1
> >  TST_NEEDS_ROOT=1
> > -TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount exportfs mount.nfs"
> > +TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount mount.nfs"

I guess that in the furture we want separate scripts for the different
hosts so that each of them can have proper metadata. I suppose that the
TST_MOUNT_DEVICE does not apply to the rhost either.

And with that we would need some kind of "master file" that would
explain which script should be executed on which host etc. But I guess
that it would be tricky to desing this properly.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Sebastian Chlad via ltp]

On Mon, Feb 23, 2026 at 5:54 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > > Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
> > > ---
> > >  testcases/network/nfs/nfs_stress/nfs_lib.sh | 22 +++++++++++++++++----
> > >  1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > > diff --git a/testcases/network/nfs/nfs_stress/nfs_lib.sh b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > > index 1ac8bd657..e52f96a5a 100644
> > > --- a/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > > +++ b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > > @@ -45,7 +45,7 @@ TST_SKIP_FILESYSTEMS="exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
> > >  TST_MOUNT_DEVICE=1
> > >  TST_FORMAT_DEVICE=1
> > >  TST_NEEDS_ROOT=1
> > > -TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount exportfs mount.nfs"
> > > +TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount mount.nfs"
>
> I guess that in the furture we want separate scripts for the different
> hosts so that each of them can have proper metadata. I suppose that the
> TST_MOUNT_DEVICE does not apply to the rhost either.
>
> And with that we would need some kind of "master file" that would
> explain which script should be executed on which host etc. But I guess
> that it would be tricky to desing this properly.

Or at least its a bit of a longterm as I see it. As of now, in the
2-host NFS setup, I install nfs-server components to artificially
satisfy the test's requirements.
The patch is the easiest way to untangle that, AFAIK.

cheers,
Seb/

>
> --
> Cyril Hrubis
> chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH v2] nfs: Adapt the lib to allow to test in 2-host mode

[Petr Vorel]

Hi Sebastian,

> nfs_lib.sh checked key server_side prerequisites on the system under test.
> In 2_host setup this incorrectly required server_side tools on lhost.

> Switch exportfs and rpc.mountd/rpc.statd checks in nfs_setup() to
> tst_rhost_run(). This aligns netns and 2-host handling in one path and
> keeps 2-host checks on rhost.

Thanks, merged!

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Petr Vorel]

> Hi!
> > > Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
> > > ---
> > >  testcases/network/nfs/nfs_stress/nfs_lib.sh | 22 +++++++++++++++++----
> > >  1 file changed, 18 insertions(+), 4 deletions(-)

> > > diff --git a/testcases/network/nfs/nfs_stress/nfs_lib.sh b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > > index 1ac8bd657..e52f96a5a 100644
> > > --- a/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > > +++ b/testcases/network/nfs/nfs_stress/nfs_lib.sh
> > > @@ -45,7 +45,7 @@ TST_SKIP_FILESYSTEMS="exfat,ext2,ext3,fuse,ntfs,vfat,tmpfs"
> > >  TST_MOUNT_DEVICE=1
> > >  TST_FORMAT_DEVICE=1
> > >  TST_NEEDS_ROOT=1
> > > -TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount exportfs mount.nfs"
> > > +TST_NEEDS_CMDS="$TST_NEEDS_CMDS mount mount.nfs"

> I guess that in the furture we want separate scripts for the different
> hosts so that each of them can have proper metadata. I suppose that the

FYI I merged v2 (ecc02095e3). I was also thinking whether add
TST_RHOST_NEEDS_CMDS (or TST_NET_NEEDS_CMDS) variable for checking rhost. My
guess is that more tests will need this check for 2 host side. And while I'm not
keen on extending tst_net.sh, it would show us that in the end something needs
to be handled in LTP metadata (LTP C API struct tst_test or some new struct
tst_net) when we rewrite tests into shell loader or even pure C API.

> TST_MOUNT_DEVICE does not apply to the rhost either.

Good point, it'd be worth to investigate why I added TST_MOUNT_DEVICE=1 and
whether it's still valid.

> And with that we would need some kind of "master file" that would
> explain which script should be executed on which host etc. But I guess
> that it would be tricky to desing this properly.

I'm not sure if separated file is worth of adding. There is tst_rhost_run()
function which should be used for checking, which works well on both netns and 2
host based setup (that's why v2).

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Cyril Hrubis]

Hi!
> > And with that we would need some kind of "master file" that would
> > explain which script should be executed on which host etc. But I guess
> > that it would be tricky to desing this properly.
> 
> I'm not sure if separated file is worth of adding. There is tst_rhost_run()
> function which should be used for checking, which works well on both netns and 2
> host based setup (that's why v2).

This is just me thinking if we can actually desing something more proper
in the future now that runltp is gone. I think that the whole
tst_rhost_run() infrastructure is a bit of a hack and that the
multimachine test can be desingned differently. I would say that more
proper solution would be to have the test split into one script per
worker and having some master script/description to drive the testing.
The testrunner would read the information about which script to run on
which worker and would also have to handle synchronization.

In the case of the NFS tests the master script would say to run a script
that sets up NFS server and signal the testrunner once it's done and
wait. The script that would be doing the actuall test would be executed
once the the NFS server script to signaled it's completion and then
start the actual test. Once it's finished testing it would exit, which
would tell the testrunner to wake up the NFS server script in order to
cleanup. If we decided to write multimachine tests this way we would
need to add a way how to pass parameters such as IP addresses from kirk
to tests and also add a way how to propagate events between tests via
kirk so that we can have some kind of locking.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Petr Vorel]

> Hi!
> > > And with that we would need some kind of "master file" that would
> > > explain which script should be executed on which host etc. But I guess
> > > that it would be tricky to desing this properly.

> > I'm not sure if separated file is worth of adding. There is tst_rhost_run()
> > function which should be used for checking, which works well on both netns and 2
> > host based setup (that's why v2).

> This is just me thinking if we can actually desing something more proper
> in the future now that runltp is gone. I think that the whole
> tst_rhost_run() infrastructure is a bit of a hack and that the
> multimachine test can be desingned differently. I would say that more
> proper solution would be to have the test split into one script per
> worker and having some master script/description to drive the testing.
> The testrunner would read the information about which script to run on
> which worker and would also have to handle synchronization.

FYI tst_rhost_run() is used for testing itself as well, more than for setup and
cleanup:

$ git grep -l tst_rhost_run |wc -l
35

Therefore we can rethink network test setup, but tst_rhost_run() will be needed
anyway.

> In the case of the NFS tests the master script would say to run a script
> that sets up NFS server and signal the testrunner once it's done and
> wait. The script that would be doing the actuall test would be executed
> once the the NFS server script to signaled it's completion and then
> start the actual test. Once it's finished testing it would exit, which
> would tell the testrunner to wake up the NFS server script in order to
> cleanup. If we decided to write multimachine tests this way we would
> need to add a way how to pass parameters such as IP addresses from kirk
> to tests and also add a way how to propagate events between tests via
> kirk so that we can have some kind of locking.

Also, you call it a hack, but it works standalone, without any runner. I would
be careful to add kirk as a hard dependency to run a single test without a
strong reason (sure, using kirk to handle metadata to run tests in paralel or
replace runtest files will be a great improvement, but I would like to still
keep executing a test itself by just calling it with proper PATH setup).

FYI "multimachine tests": I know only about 1 test which needs more than a
single machine: IPsec (implemented in openQA instead of LTP [1]).

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/issues/920

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Cyril Hrubis]

Hi!
> > > > And with that we would need some kind of "master file" that would
> > > > explain which script should be executed on which host etc. But I guess
> > > > that it would be tricky to desing this properly.
> 
> > > I'm not sure if separated file is worth of adding. There is tst_rhost_run()
> > > function which should be used for checking, which works well on both netns and 2
> > > host based setup (that's why v2).
> 
> > This is just me thinking if we can actually desing something more proper
> > in the future now that runltp is gone. I think that the whole
> > tst_rhost_run() infrastructure is a bit of a hack and that the
> > multimachine test can be desingned differently. I would say that more
> > proper solution would be to have the test split into one script per
> > worker and having some master script/description to drive the testing.
> > The testrunner would read the information about which script to run on
> > which worker and would also have to handle synchronization.
> 
> FYI tst_rhost_run() is used for testing itself as well, more than for setup and
> cleanup:
> 
> $ git grep -l tst_rhost_run |wc -l
> 35
> 
> Therefore we can rethink network test setup, but tst_rhost_run() will be needed
> anyway.

What I'm thinking about is to replace the tst_rhost_run() with a
synchronization between multiple tests scripts. With that a script can
wait for some kind of event instead of running the code itself.

It would be far more flexible approach than what we have now. With that
we could easily scale to tests with three or more machines that are
impossible to implement at the moment. But of course unless we actually
write a proof of a concept we will not be able fully understand if this
concept is going to be better or not.

> > In the case of the NFS tests the master script would say to run a script
> > that sets up NFS server and signal the testrunner once it's done and
> > wait. The script that would be doing the actuall test would be executed
> > once the the NFS server script to signaled it's completion and then
> > start the actual test. Once it's finished testing it would exit, which
> > would tell the testrunner to wake up the NFS server script in order to
> > cleanup. If we decided to write multimachine tests this way we would
> > need to add a way how to pass parameters such as IP addresses from kirk
> > to tests and also add a way how to propagate events between tests via
> > kirk so that we can have some kind of locking.
> 
> Also, you call it a hack, but it works standalone, without any runner. I would
> be careful to add kirk as a hard dependency to run a single test without a
> strong reason (sure, using kirk to handle metadata to run tests in paralel or
> replace runtest files will be a great improvement, but I would like to still
> keep executing a test itself by just calling it with proper PATH setup).

It should be possible to design the system so that tests can be executed
with a simpler solution than kirk.

Also it's not as standalone as you may think. You need to 1) start two
machines and manually install LTP there 2) write the IP addresses into
the configuration and only once that is done you can execute tests on
two machines.

> FYI "multimachine tests": I know only about 1 test which needs more than a
> single machine: IPsec (implemented in openQA instead of LTP [1]).

I think that this is because our multimachine design is not as easy to
use as it should be.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Petr Vorel]

> Hi!
> > > > > And with that we would need some kind of "master file" that would
> > > > > explain which script should be executed on which host etc. But I guess
> > > > > that it would be tricky to desing this properly.

> > > > I'm not sure if separated file is worth of adding. There is tst_rhost_run()
> > > > function which should be used for checking, which works well on both netns and 2
> > > > host based setup (that's why v2).

> > > This is just me thinking if we can actually desing something more proper
> > > in the future now that runltp is gone. I think that the whole
> > > tst_rhost_run() infrastructure is a bit of a hack and that the
> > > multimachine test can be desingned differently. I would say that more
> > > proper solution would be to have the test split into one script per
> > > worker and having some master script/description to drive the testing.
> > > The testrunner would read the information about which script to run on
> > > which worker and would also have to handle synchronization.

> > FYI tst_rhost_run() is used for testing itself as well, more than for setup and
> > cleanup:

> > $ git grep -l tst_rhost_run |wc -l
> > 35

> > Therefore we can rethink network test setup, but tst_rhost_run() will be needed
> > anyway.

> What I'm thinking about is to replace the tst_rhost_run() with a
> synchronization between multiple tests scripts. With that a script can
> wait for some kind of event instead of running the code itself.

> It would be far more flexible approach than what we have now. With that
> we could easily scale to tests with three or more machines that are
> impossible to implement at the moment. But of course unless we actually
> write a proof of a concept we will not be able fully understand if this
> concept is going to be better or not.

> > > In the case of the NFS tests the master script would say to run a script
> > > that sets up NFS server and signal the testrunner once it's done and
> > > wait. The script that would be doing the actuall test would be executed
> > > once the the NFS server script to signaled it's completion and then
> > > start the actual test. Once it's finished testing it would exit, which
> > > would tell the testrunner to wake up the NFS server script in order to
> > > cleanup. If we decided to write multimachine tests this way we would
> > > need to add a way how to pass parameters such as IP addresses from kirk
> > > to tests and also add a way how to propagate events between tests via
> > > kirk so that we can have some kind of locking.

> > Also, you call it a hack, but it works standalone, without any runner. I would
> > be careful to add kirk as a hard dependency to run a single test without a
> > strong reason (sure, using kirk to handle metadata to run tests in paralel or
> > replace runtest files will be a great improvement, but I would like to still
> > keep executing a test itself by just calling it with proper PATH setup).

> It should be possible to design the system so that tests can be executed
> with a simpler solution than kirk.

+1

> Also it's not as standalone as you may think. You need to 1) start two
> machines and manually install LTP there 2) write the IP addresses into
> the configuration and only once that is done you can execute tests on
> two machines.

Yes, that's job of the framework executor (kirk, openQA, TuxMake, Fuego, Lava,
etc).

Yes, but when there is some bug which needs to be bisected, the fastest approach
for network tests is to run with rapido over netns. New approach should keep
support for netns and real host. Of course real communication over network is
not the same as using netns, but quite a lot of bugs can be caught this way.

> > FYI "multimachine tests": I know only about 1 test which needs more than a
> > single machine: IPsec (implemented in openQA instead of LTP [1]).

> I think that this is because our multimachine design is not as easy to
> use as it should be.

I'm not saying that there is not a requirement for 3+ machines tests just
because I don't see it :). But it would be kind of some special tests
(normally stressing a server is kind of test scenario for multi machine
tests).

And the reason why I'm asking question "do we need it?" is that I know how many
tests we have to rewrite (+ generally how much of LTP rewrite is unfinished,
including readthedoc migration).

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH] nfs: Adapt the lib to allow to test in 2-host mode

[Sebastian Chlad]

On Tue, 24 Feb 2026 at 17:11, Petr Vorel <pvorel@suse.cz> wrote:

> > Hi!
> > > > > > And with that we would need some kind of "master file" that would
> > > > > > explain which script should be executed on which host etc. But I
> guess
> > > > > > that it would be tricky to desing this properly.
>
> > > > > I'm not sure if separated file is worth of adding. There is
> tst_rhost_run()
> > > > > function which should be used for checking, which works well on
> both netns and 2
> > > > > host based setup (that's why v2).
>
> > > > This is just me thinking if we can actually desing something more
> proper
> > > > in the future now that runltp is gone. I think that the whole
> > > > tst_rhost_run() infrastructure is a bit of a hack and that the
> > > > multimachine test can be desingned differently. I would say that more
> > > > proper solution would be to have the test split into one script per
> > > > worker and having some master script/description to drive the
> testing.
> > > > The testrunner would read the information about which script to run
> on
> > > > which worker and would also have to handle synchronization.
>
> > > FYI tst_rhost_run() is used for testing itself as well, more than for
> setup and
> > > cleanup:
>
> > > $ git grep -l tst_rhost_run |wc -l
> > > 35
>
> > > Therefore we can rethink network test setup, but tst_rhost_run() will
> be needed
> > > anyway.
>
> > What I'm thinking about is to replace the tst_rhost_run() with a
> > synchronization between multiple tests scripts. With that a script can
> > wait for some kind of event instead of running the code itself.
>
> > It would be far more flexible approach than what we have now. With that
> > we could easily scale to tests with three or more machines that are
> > impossible to implement at the moment. But of course unless we actually
> > write a proof of a concept we will not be able fully understand if this
> > concept is going to be better or not.
>
> > > > In the case of the NFS tests the master script would say to run a
> script
> > > > that sets up NFS server and signal the testrunner once it's done and
> > > > wait. The script that would be doing the actuall test would be
> executed
> > > > once the the NFS server script to signaled it's completion and then
> > > > start the actual test. Once it's finished testing it would exit,
> which
> > > > would tell the testrunner to wake up the NFS server script in order
> to
> > > > cleanup. If we decided to write multimachine tests this way we would
> > > > need to add a way how to pass parameters such as IP addresses from
> kirk
> > > > to tests and also add a way how to propagate events between tests via
> > > > kirk so that we can have some kind of locking.
>
> > > Also, you call it a hack, but it works standalone, without any runner.
> I would
> > > be careful to add kirk as a hard dependency to run a single test
> without a
> > > strong reason (sure, using kirk to handle metadata to run tests in
> paralel or
> > > replace runtest files will be a great improvement, but I would like to
> still
> > > keep executing a test itself by just calling it with proper PATH
> setup).
>
> > It should be possible to design the system so that tests can be executed
> > with a simpler solution than kirk.
>
> +1
>
> > Also it's not as standalone as you may think. You need to 1) start two
> > machines and manually install LTP there 2) write the IP addresses into
> > the configuration and only once that is done you can execute tests on
> > two machines.
>
> Yes, that's job of the framework executor (kirk, openQA, TuxMake, Fuego,
> Lava,
> etc).
>
> Yes, but when there is some bug which needs to be bisected, the fastest
> approach
> for network tests is to run with rapido over netns. New approach should
> keep
> support for netns and real host. Of course real communication over network
> is
> not the same as using netns, but quite a lot of bugs can be caught this
> way.
>
> > > FYI "multimachine tests": I know only about 1 test which needs more
> than a
> > > single machine: IPsec (implemented in openQA instead of LTP [1]).
>

FYI openQA has many multimachine tests.
Also in the openqa the multimachine tests are done exactly with localapi,
so basically semaphores.

Personally for development and testing of the ltp 2-hosts I used:
https://github.com/dmacvicar/terraform-provider-libvirt
Yeah, terraform. I imagine hooking things up together so
that terraform-provider-libvirt provides VMs with needed IPs and what not,
and kirk connects to SUT over ssh and the ltp nfs tests simply run the
tests, should be simple exercise.

I do not see a problem with lhost being a driver for net/nfs tests run on 2
machines.
But if we see a need, we could also provide a sort of lock api, so nodes of
multimachine tests could be synchronized that way too.
I guess those approaches are complementary, not exclusive.


>
> > I think that this is because our multimachine design is not as easy to
> > use as it should be.
>
> I'm not saying that there is not a requirement for 3+ machines tests just
> because I don't see it :). But it would be kind of some special tests
> (normally stressing a server is kind of test scenario for multi machine
> tests).
>
> And the reason why I'm asking question "do we need it?" is that I know how
> many
> tests we have to rewrite (+ generally how much of LTP rewrite is
> unfinished,
> including readthedoc migration).
>
> Kind regards,
> Petr
>

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp