[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
>