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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > >> [email protected] <mailto:[email protected]> > >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev > <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > >> > > > > _______________________________________________ > > dev mailing list > > [email protected] <mailto:[email protected]> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
