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

Seena Fallah seenafallah at gmail.com
Fri Nov 12 11:30:39 UTC 2021


Well, as like as --db-nb-create-insecure-remote=yes arg the inactivity
probe can be set with args so I think the current implementation would be
better to deal with this problem. (Maybe just change the arg name)

I want to listen to specific IP so solution #3 won't be good for me!
Creating multiple connections and going to be ignored on hosts I don't
think would be a good practice because when you create multiple remotes it
shows that it should go through all hosts (for example creating remotes
with punix) and so I don't think creating multiple remotes and find out
which to listen would be good!

Maybe another method that could define local configs for nodes in cluster
mode would be better but now Wouldn't it better to move with this
implementation?

On Tue, Nov 2, 2021 at 2:05 AM Ilya Maximets <i.maximets at ovn.org> wrote:

> 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