[ovs-dev] [PATCH] ovsdb-server: add inactivity probe arg to ovsdb server

Ilya Maximets i.maximets at ovn.org
Mon Nov 1 22:35:40 UTC 2021


On 10/28/21 19:17, Seena Fallah wrote:
> Just wanted to ping you guys for my question :)

Hi.  Sorry things are taking so long.
Replies inline.

Best regards, Ilya Maximets.

> 
> On Wed, Oct 20, 2021 at 2:11 AM Seena Fallah <seenafallah at gmail.com <mailto:seenafallah at gmail.com>> wrote:
> 
>     I'm trying to write the test for it but because I faced and verify the issue over ovn I can't find the way to verify where can I verify that inactivity_probe is set correctly. Can you give me a hint to find out the inactivity probe for the connection in ovs?

I don't think there is a way to directly check the configuration.
What you can do is to configure the value and wait (with time warping)
until the probe is sent.

> 
>     Thanks
> 
>     On Sat, Oct 16, 2021 at 1:10 AM Seena Fallah <seenafallah at gmail.com <mailto:seenafallah at gmail.com>> wrote:
> 
>         Thanks for your notes. Well because I'm much comfortable with Github features if it's okay I continue to push further changes in Github.
> 
>         The reason I add this cmdline arg is creating dedicated remotes for each ovsdb server seems only available with cmdline. For example, I want each ovsdb server to listen on their host IP address and if I set it via database it will apply on all DBs and so when I set to listen on x.x.x.x just one host can listen on and others raise an error that they can't.
>         So I added this arg to help setting probe interval for those connections that initialized with cmdline args and not stored in DB.

I understand the issue, but I'm not sure about the solution.
AFAICT, configuration through the database was added specifically
to avoid adding numerous command-line arguments.  As if we're
adding configuration for inactivity probes, we should also add
configuration for backoffs and, probably, some other stuff in
the future.  Second thing is that '--inactivity-probe' is a very
generic name and it will confuse users, because it's unclear to
what type of connections it will be applied.  It should affect
all connections at once (db-based, cmdline-based, relay,
replication, controller, management, ...) or have a very distinct
name.  And I'm not sure what would be a good name for this kind
of option.  It's also unclear if the config should be applied
to connections created by ovsdb-server itself or connections
configured inside the database for users of that database
(ovs-vswitchd, ovn-controller, etc.)

Here is the list of possible solutions that I can think of with
no particular order:

1. Do nothing.
   As you said, you can configure connection through the database.
   One of the servers (the one that has this IP) will succeed,
   others will fail.  So, if you'll add 3 connections, each of
   the servers should successfully open 1 connection and fail
   2 other connections.  Should work fine, but there will be
   some warnings in the logs.

2. Same as 1, but we could additionally figure out how to
   distinguish connections, so servers will not try to open ones
   that cannot be open on a particular host.  e.g. add a --local-ip
   argument and restrict ovsdb-server to only create passive
   connections with that IP and ignore connections with other IPs.

3. Don't listen on particular IP, but use 0.0.0.0 instead,
   if the setup allows.

4. Create a separate small standalone database and use it to
   configure connections for each server.

5. Create a generic common parameter that will affect every
   connection by changing the value of
   RECONNECT_DEFAULT_PROBE_INTERVAL, e.g.,
   "--reconnect-default-probe-interval".
   Not sure, how useful that is though.

What do you think?
I'm leaning toward solution #2.
#3 is the most simple, if you can do that in your setup.

> 
>         I'll add a unit test for it. For the documentation is it enough to add it to `ovsdb-server --help` output or for example should I add it to the NEWS file or...?

All new user-visible options should go to the NEWS file.
And man pages should be updated, at least.

> 
>         Thanks.
> 
>         On Fri, Oct 15, 2021 at 10:50 PM Ilya Maximets <i.maximets at ovn.org <mailto:i.maximets at ovn.org>> wrote:
> 
>             On 10/15/21 19:07, Michael Santana wrote:
>             >
>             >
>             > On 10/14/21 8:45 PM, Seena Fallah wrote:
>             >> Hi,
>             >>
>             >> I've made a patch in GitHub https://github.com/openvswitch/ovs/pull/371 <https://github.com/openvswitch/ovs/pull/371>
>             >> Please review it.
>             > Hi Seena,
>             >
>             > We don't review pull request on github. The way to contribute is to send your patch to the mailing list.
> 
>             Well, that is not true.  Open vSwitch project does accept
>             pull requests.  The chances for a patch to be reviewed in
>             time are higher on a mail-list though, since it's still a
>             main way to submit patches and only few people are actually
>             getting notifications from github.
> 
>             Seena, I'll take a look at your patch on next week.  You
>             may send it to the mail-list to hit a wider audience if
>             you want.  At the first glance, I'd say that documentation
>             updates and unit tests are missing in the patch.  Also,
>             there is a way to configure these advanced parameters while
>             adding remotes via the database, so I would like to know
>             why this doesn't work for you and you need extra cmdline
>             arguments?
> 
>             Best regards, Ilya Maximets.
> 
>             > Take a look at the other patches on the mailing list so you get an idea. To send your patch you must first generate the patch using `git format-patch`. Once the patch is generated you must then send it to the mailing list (best using `git send-email`)
>             >
>             > For more info please take a look at our contributing doc [1]
>             >
>             > If you have questions please dont hesitate to ask
>             >
>             > [1] - https://docs.openvswitch.org/en/latest/internals/contributing/submitting-patches/ <https://docs.openvswitch.org/en/latest/internals/contributing/submitting-patches/>
>             >>
>             >> Thanks.
>             >> _______________________________________________
>             >> dev mailing list
>             >> dev at openvswitch.org <mailto:dev at openvswitch.org>
>             >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev <https://mail.openvswitch.org/mailman/listinfo/ovs-dev>
>             >>
>             >
>             > _______________________________________________
>             > dev mailing list
>             > dev at openvswitch.org <mailto:dev at openvswitch.org>
>             > https://mail.openvswitch.org/mailman/listinfo/ovs-dev <https://mail.openvswitch.org/mailman/listinfo/ovs-dev>
>             >
> 



More information about the dev mailing list