[ovs-dev] [PATCH v5 00/21] Daemon mode for ovn-nbctl

Jakub Sitnicki jkbs at redhat.com
Thu Jul 19 18:09:33 UTC 2018


Thanks for starting the discussion, Mark.

On Thu, 19 Jul 2018 12:26:24 -0400
Mark Michelson <mmichels at redhat.com> wrote:

> On 07/19/2018 09:51 AM, Jakub Sitnicki wrote:

(...)

> > The changes are functional to the point that all test cases in the ovn-nbctl
> > test suite (tests/ovn-nbctl.at) and OVN test suite (tests/ovn.at) pass when
> > running ovn-nbctl as a daemon [2].
> > 
> > However, I'm still thinking how to nicely integrate the daemon mode with the
> > test suite so that the existing tests can be run using either the normal or the
> > daemon mode. Any ideas?  
> 
> When I think about this, I think of two obstacles:
> 1) What is a good way to run a test under both daemon mode and 
> non-daemon mode?
> 2) What is the best way to compose a test that will run under both 
> daemon mode and non-daemon mode
> 
> (2) seems like the easier problem to mechanically solve. You can perform 
> a find and replace to change all current instances of `ovn-nbctl` to 
> some bash function. The bash function could determine whether daemon 
> mode is in use. If not in daemon mode, call `ovn-nbctl` directly. If in 
> daemon mode, call `ovs-appctl -t ovn-nbctl run`.
> 
> This isn't a good long term solution though. It will be difficult to 
> enforce the use of the bash function instead of calling ovn-nbctl. A 
> potentially better long-term solution would be not to require ovs-appctl 
> when communicating with the ovn-nbctl daemon. If ovn-nbctl could be 
> called directly, it would make things easier.

As it happens, in the test suite, ovn-nbctl is an alias for a shell
function already [1].

That is something I thought we can leverage. At least until we turn
ovn-nbctl tool into a JSON-RPC client that will control the daemon
(which ideally should work out-of-the-box if the daemon is running).

For now, we could have a wrapper around 'ovs-appctl -t ovn-nbctl run'
that tries to act like ovn-nbctl. I have a very crude prototype of
that [2] which screams for a rewrite in Python :-)

> 
> (1) is a bit more tricky in my opinion.
> 
> One idea would be to pass in a flag to the testsuite that says to start 
> an ovn-nbctl daemon when ovn_start() is called. This way, the entire 
> runthrough of the test would be for ovn-nbctl daemon mode. In CI 
> systems, we'd want to perform two runs of the testsuite, one in daemon 
> mode, and one not in daemon mode. This idea is a bit overkill though 
> since most tests in the testsuite are not even OVN tests. This also 
> doesn't scale well in case there become other ways we want to run 
> variants of existing tests.
> 
> A better idea is to somehow make existing tests that use ovn-nbctl run 
> once in daemon mode and once in non-daemon mode. This is difficult, 
> though, because the structure of the tests doesn't allow for an easy way 
> to repeat the test. The "easiest" way I can think to do this is to 
> modify the existing ovn test files to be .in files that at build time 
> generate a daemon version of the test and a non-daemon version of the 
> test. Notice "easiest" in quotation marks though. The advantage of doing 
> it this way is that it simultaneously clears up problem (2) as well 
> since the autogenerated files will have the proper invocations in them.

I agree this is the trickier part.

I was also thinking about introducing a flag that controls if ovn-nbctl
runs in daemon mode or regular mode throughout the tests. If we had
that we could do a second pass only on tests that match on the 'ovn'
keyword.

I haven't thought of generating two variants of tests. That also sounds
interesting. Maybe that would be doable straight from m4, without going
through generating files from templates.

One more thing to consider is that point where we have to start/stop
the daemon differs from test suite to test suite. For tests/ovn.at that
would be ovn_start/OVN_CLEANUP (with one exception [3]). But for
tests/ovn-nbctl.at this would be OVN_NBCTL_TEST_{START,STOP}. That
seems less of problem though.

-Jakub

[1] https://github.com/openvswitch/ovs/blob/master/tests/ovs-macros.at#L135
[2] https://github.com/jsitnicki/ovs/commit/c34ef03fc11e94e61c57edbfb3e968eacbf07ffb#diff-0c2aae317387234fe3f3e3f28313cf63R32
[3] https://github.com/openvswitch/ovs/blob/master/tests/ovn.at#L6376


More information about the dev mailing list