| *** rpittau|afk is now known as rpittau | 07:07 | |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/neutron master: Do less locking on l3 agent greenpool resize https://review.opendev.org/c/openstack/neutron/+/806325 | 07:36 |
|---|---|---|
| gryf | hi. I'm trying to setup multinode setup with ovn-cotavia-provider. do I need to set something specific on the compute node? | 07:42 |
| *** mgoddard- is now known as mgoddard | 07:58 | |
| opendevreview | Bernard Cafarelli proposed openstack/neutron-vpnaas stable/train: Pin isort to 4.3.21 https://review.opendev.org/c/openstack/neutron-vpnaas/+/805969 | 08:10 |
| *** ykarel is now known as ykarel|lunch | 08:24 | |
| opendevreview | liuyulong proposed openstack/neutron master: Async call RPC update_device_list https://review.opendev.org/c/openstack/neutron/+/806329 | 08:26 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron-vpnaas stable/train: Pin isort to 4.3.21 https://review.opendev.org/c/openstack/neutron-vpnaas/+/805969 | 08:43 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron-vpnaas stable/train: Pin isort to 4.3.21 https://review.opendev.org/c/openstack/neutron-vpnaas/+/805969 | 09:30 |
| *** ykarel|lunch is now known as ykarel | 10:04 | |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Check quota limits https://review.opendev.org/c/openstack/neutron/+/801470 | 10:17 |
| ralonsoh | bcafarel, https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_39c/805969/7/check/neutron-vpnaas-tempest/39c5a8d/job-output.txt | 10:27 |
| ralonsoh | I don't know how it was working before | 10:27 |
| ralonsoh | I don't see where neutron-tempest-plugin is installed | 10:27 |
| ralonsoh | ah yes, neutron-tempest-plugin-vpnaas based on neutron-tempest-plugin-base | 10:28 |
| ralonsoh | and this requires n-t-p | 10:28 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Write FW OF rules belonging to a port in a single operation https://review.opendev.org/c/openstack/neutron/+/806246 | 10:53 |
| ykarel | ralonsoh, slaweq when you get chance https://review.opendev.org/c/openstack/networking-bgpvpn/+/806101 | 11:03 |
| ralonsoh | let me check | 11:04 |
| slaweq | ykarel: done | 11:19 |
| ykarel | Thanks ralonsoh slaweq | 11:25 |
| bcafarel | ralonsoh: yes I am not sure where it fails to get neutron-tempest-plugin :/ https://opendev.org/openstack/neutron-vpnaas/src/branch/stable/train/.zuul.yaml#L26 seems to me it should checkout and use it properly | 12:07 |
| opendevreview | Merged openstack/neutron stable/wallaby: Follow up for replacing assertItemsEqual https://review.opendev.org/c/openstack/neutron/+/805792 | 12:19 |
| opendevreview | Merged openstack/neutron-lib master: Add Local IP API def https://review.opendev.org/c/openstack/neutron-lib/+/803051 | 12:27 |
| opendevreview | Merged openstack/networking-bgpvpn master: Use assertCountEqual instead of assertItemsEqual https://review.opendev.org/c/openstack/networking-bgpvpn/+/806101 | 12:37 |
| spatel | ralonsoh morning! | 13:04 |
| ralonsoh | hello | 13:06 |
| spatel | My problem has been resolved | 13:07 |
| opendevreview | Takashi Kajinami proposed openstack/neutron master: Use importlib instead of imp https://review.opendev.org/c/openstack/neutron/+/804596 | 13:07 |
| spatel | I can spin up sriov and everything works great! | 13:07 |
| ralonsoh | nice to read that | 13:07 |
| opendevreview | Takashi Kajinami proposed openstack/neutron master: Use importlib instead of imp https://review.opendev.org/c/openstack/neutron/+/804596 | 13:09 |
| spatel | ralonsoh you said we have to host metadata on gateway node just curious because i did nothing and everything working fine. | 13:11 |
| spatel | just curious if that issue has been fixed and doc is outdated | 13:11 |
| spatel | ralonsoh my goal is to run OVN in production so try to find every single blocker :) | 13:12 |
| ralonsoh | no, this is mandatory | 13:12 |
| spatel | I can see no namespace on compute node - ip netns list | 13:14 |
| spatel | how does my metadata service working here, huh? | 13:15 |
| ralonsoh | the metadata for sriov ports in on the GW | 13:15 |
| spatel | hmm! i have 3 node in lab 1 controller and 2 compute nodes | 13:18 |
| spatel | out of 2 compute 1 is normal compute and other one is sriov node | 13:19 |
| spatel | i can see (ip netns) on normal compute node so assuming its my network GW and sriov compute node using it as a proxy | 13:19 |
| spatel | am i correct? | 13:19 |
| spatel | let me do tcpdump to see packet flow | 13:20 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add pagging and sorting support for "network_ip_availability" https://review.opendev.org/c/openstack/neutron/+/806404 | 13:32 |
| *** rpittau is now known as rpittau|afk | 13:42 | |
| spatel | ralonsoh i can see SRIOV compute node sending metada traffic to general compute nodes | 13:49 |
| ralonsoh | spatel, http://dani.foroselectronica.es/ovn-external-ports-604/ | 13:57 |
| ralonsoh | https://opendev.org/openstack/networking-ovn/commit/eb696ca703d1aaf168c54f37e0a25516e8953e5b | 13:58 |
| slaweq | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Aug 27 14:00:36 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| slaweq | hi | 14:00 |
| mlavalle | o/ | 14:00 |
| ralonsoh | hello | 14:00 |
| amotoki | hi | 14:00 |
| thomasb06 | hi | 14:00 |
| njohnston | o/ | 14:00 |
| lajoskatona | Hi | 14:00 |
| slaweq | I think we can start as we have quorum today | 14:01 |
| slaweq | and I want to start today in a different way | 14:01 |
| haleyb | hi | 14:01 |
| slaweq | #topic On Demand Agenda | 14:01 |
| slaweq | hi haleyb | 14:01 |
| slaweq | welcome back :) | 14:01 |
| slaweq | first - congratulations to Lajos, our new PTL! | 14:02 |
| ralonsoh | congrats!!! | 14:02 |
| lajoskatona | thanks | 14:02 |
| amotoki | congrats, lajoskatona | 14:02 |
| mlavalle | +1 | 14:02 |
| slaweq | and regarding that I have a question to all of You | 14:02 |
| njohnston | Congratulations Lajos! | 14:02 |
| slaweq | I think that lajoskatona should now be part of the drivers team | 14:03 |
| ralonsoh | I think so, makes sense | 14:03 |
| njohnston | +1 | 14:03 |
| slaweq | even if he wouldn't be ptl, I think he deserves that | 14:03 |
| slaweq | but now even more :) | 14:03 |
| mlavalle | +1 | 14:03 |
| slaweq | do You think I should send official email with nomination for lajoskatona or would it be enough if we will vote here? | 14:03 |
| ralonsoh | this meeting will be registered, so it is "legal" | 14:04 |
| isabek | Congratulations lajoskatona ! | 14:04 |
| amotoki | most of voters are here and it looks enough to vote here. | 14:04 |
| ralonsoh | +1 | 14:04 |
| slaweq | so let's vote :) | 14:05 |
| mlavalle | +1 again | 14:06 |
| ralonsoh | +1 | 14:06 |
| haleyb | +1 | 14:06 |
| amotoki | +1 | 14:06 |
| slaweq | +1 of course :) | 14:06 |
| slaweq | njohnston: and You? | 14:06 |
| mlavalle | I would still send a message to the ML communicating the decision we just took here | 14:07 |
| slaweq | mlavalle: yes, I will do it | 14:07 |
| amotoki | mlavalle: totally agree | 14:07 |
| mlavalle | noit nominating. just communicating | 14:07 |
| slaweq | but I was just hoping we don't need to wait e.g. 1 week for votes there | 14:07 |
| slaweq | as we are all here :) | 14:07 |
| lajoskatona | thanks for the tust :-) | 14:08 |
| slaweq | I think njohnston already voted above, so - welcome lajoskatona in the drivers team also | 14:08 |
| slaweq | and congratulations | 14:08 |
| slaweq | let's move on | 14:09 |
| slaweq | another quick topic | 14:09 |
| slaweq | I proposed already patch with cycle highlights for Xena: https://review.opendev.org/c/openstack/releases/+/805610 | 14:09 |
| slaweq | please check it if You have time, especially from english PoV :) | 14:10 |
| slaweq | thx in advance | 14:10 |
| slaweq | and now, let's move on to the RFEs | 14:10 |
| slaweq | #topic RFEs | 14:10 |
| slaweq | we have 2 RFEs for today | 14:10 |
| slaweq | first one | 14:10 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1936408 | 14:10 |
| ralonsoh | thanks | 14:11 |
| ralonsoh | first of all, a link to POC: https://review.opendev.org/q/topic:%22bug%252F1936408%22+(status:open%20OR%20status:merged) | 14:11 |
| ralonsoh | what I'm proposing here is *NOT* to change the default API behaviour | 14:11 |
| ralonsoh | what I want here (a customer) is to, somehow, raise an exception if we a lowering a quota limit under the current usage | 14:12 |
| ralonsoh | and what I'm proposing is something like Nova API --force (but the opposite, because we always force the quota update) | 14:12 |
| ralonsoh | with this new parameter, --check-limit, the Neutron server will check the resource usage before updating it | 14:12 |
| ralonsoh | that's all, thanks | 14:12 |
| njohnston | I think this is fine, with the clarifications I am ok with the concept | 14:14 |
| slaweq | ralonsoh: I was yesterday thinking about it and about how nova behaves there | 14:15 |
| slaweq | maybe You could add flag "--force" as nova do but for now defaults it to True to have not changed our api | 14:15 |
| amotoki | it sounds good as neutron API. | 14:15 |
| amotoki | From POV of OSC, we will have three modes now: using API default behavior, --force (for nova) and --check-limit (for neutron) | 14:15 |
| slaweq | in the future we can maybe communicate it more widely and change behaviour to be same as nova | 14:15 |
| ralonsoh | hmmmm I see slaweq's point | 14:16 |
| amotoki | it may be nice if OSC behavior --force or --check-limit :) | 14:16 |
| ralonsoh | to have only one parameter, force | 14:16 |
| ralonsoh | and for network commands, use always "force" | 14:16 |
| ralonsoh | ok ok, but this is a boolean parameter | 14:16 |
| ralonsoh | we need the opposite | 14:16 |
| ralonsoh | slaweq, we can't use this | 14:16 |
| ralonsoh | we need something like --no-force | 14:16 |
| ralonsoh | I think we should use --check-limit | 14:17 |
| slaweq | ralonsoh: I'm talking about server side parameter which will by default be like force=True | 14:17 |
| ralonsoh | yes | 14:17 |
| slaweq | in OSC it can be implemented as --no-force | 14:17 |
| slaweq | I'm not exactly sure how nova do that on server side really | 14:17 |
| ralonsoh | this is less intuitive than --check-limit | 14:18 |
| slaweq | I know | 14:18 |
| ralonsoh | but whatever you decide | 14:18 |
| slaweq | my point was that at some point we may deprecate old behaviour and be consistent with nova | 14:18 |
| slaweq | but that's just an idea | 14:18 |
| slaweq | I'm ok with --check-limit as well | 14:18 |
| ralonsoh | so what do you vote here? 1) --check-limit or 2) --no-force ? | 14:19 |
| njohnston | 1 | 14:19 |
| amotoki | --check-limit sounds better as it looks clearer to me | 14:20 |
| mlavalle | overall I'm ok with the proposal. I don't like it though, from a OpenStack perspective. We are giving users contradictory behaviors among services. So at least let's try to be clear and I think --check-limit is clearer | 14:20 |
| lajoskatona | +1 on check-limit | 14:20 |
| ralonsoh | thank you all for your ideas and votes | 14:21 |
| slaweq | I'm fine with check-limit too :) | 14:21 |
| mlavalle | and maybe, over time, try to converge to a consistent behavior community wide | 14:21 |
| ralonsoh | for sure, we need that | 14:21 |
| mlavalle | there are no neutron users. there are openstack users | 14:22 |
| slaweq | ok, I will mark this rfe as approved and let's go with --check-limit option in API for now | 14:24 |
| slaweq | thx ralonsoh for proposing that | 14:24 |
| ralonsoh | thanks! | 14:24 |
| slaweq | next rfe | 14:25 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1939602 | 14:25 |
| ralonsoh | thanks | 14:25 |
| ralonsoh | first of all, the POC: https://review.opendev.org/c/openstack/neutron/+/803034 | 14:25 |
| ralonsoh | the idea is to have a memory profiler FOR TESTING ONLY | 14:25 |
| ralonsoh | I say that because that will impact in the performance | 14:25 |
| ralonsoh | this memory profiler could be useful to detect memory leaks in new modules | 14:26 |
| ralonsoh | every x seconds, this service plugin will print memory stats | 14:26 |
| ralonsoh | and the admin can filter by module | 14:26 |
| ralonsoh | and the number of stats needed | 14:26 |
| ralonsoh | --> https://review.opendev.org/c/openstack/neutron/+/803034/5/neutron/services/memory_profiler/plugin.py | 14:26 |
| ralonsoh | that's basically what I'm proposing. This is not something for a production environment but could be useful for testing | 14:27 |
| ralonsoh | that's all, thanks | 14:27 |
| ralonsoh | (btw, CI is not passing but this patch works, you can test it) | 14:28 |
| slaweq | I'm ok with that idea as optional plugin | 14:30 |
| slaweq | but we will have to discuss if we want to add new ci job with it or maybe enable it in some (all) of the existing jobs | 14:30 |
| ralonsoh | periodic job? | 14:30 |
| slaweq | could be, probably better than adding new job to check queue | 14:30 |
| ralonsoh | I think so | 14:31 |
| slaweq | but tbh I don't see huge performance impact and job time difference between neutron-ovn-tempest-ovs-release and neutron-ovn-tempest-memory-profiler | 14:32 |
| lajoskatona | it looks similar to loki | 14:32 |
| slaweq | and both jobs runs same tests | 14:32 |
| slaweq | so maybe it can be enabled in existing jobs simply? | 14:32 |
| slaweq | we can discuss that later in the ci meeting for sure :) | 14:32 |
| lajoskatona | for loki we have experimental job as I see | 14:32 |
| lajoskatona | but yeah we can discuss on CI meeting | 14:33 |
| ralonsoh | yes, I think we can add it to experimental queue, same as loki | 14:33 |
| ralonsoh | ok to discuss it in CI meeting | 14:33 |
| njohnston | I think this is a very useful idea. Is there any way to quantify how bad the performance penalty is? Some guidance anywhere from "10% slowdown" to "4000% slowdown and cannot ever be activated even in light production use" would be helpful. Someone facing a memory leak in prod is likely to at least think twice about possibly enabling this. | 14:34 |
| ralonsoh | njohnston, yes, I need to benchmark it | 14:34 |
| ralonsoh | this will be running in a parallel thread and memory snapshots are expensive | 14:35 |
| ralonsoh | but it will affect only one worker | 14:35 |
| ralonsoh | (actually, I can print the time spent on printing the memory stats, that could be very easy and helpful for benchmarking) | 14:38 |
| njohnston | +1 | 14:38 |
| slaweq | I'm +1 on this RFE | 14:39 |
| lajoskatona | +1 | 14:39 |
| amotoki | +1 on the RFE | 14:39 |
| ralonsoh | thank you all, I'll bring this topic again next week in the CI meeting | 14:39 |
| haleyb | +1 | 14:39 |
| ralonsoh | thank you for your time | 14:40 |
| slaweq | mlavalle: any thoughts on this one? | 14:41 |
| mlavalle | +1 | 14:41 |
| slaweq | thx | 14:43 |
| slaweq | so I will mark that RFE as approved too | 14:43 |
| slaweq | thx ralonsoh for proposing it | 14:43 |
| ralonsoh | thanks | 14:43 |
| slaweq | and that's all for this week from me | 14:43 |
| slaweq | do You have anything else You would like to discuss? | 14:43 |
| *** ykarel is now known as ykarel|away | 14:43 | |
| amotoki | nothing from me | 14:44 |
| mlavalle | not from me | 14:44 |
| ralonsoh | nothing, thanks | 14:44 |
| slaweq | thx for attending the meeting today | 14:46 |
| njohnston | thanks slaweq, congrats again lajoskatona | 14:46 |
| slaweq | have a great weekend and see You online next week :) | 14:46 |
| slaweq | o/ | 14:46 |
| slaweq | #endmeeting | 14:46 |
| opendevmeet | Meeting ended Fri Aug 27 14:46:29 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:46 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-08-27-14.00.html | 14:46 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-08-27-14.00.txt | 14:46 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-08-27-14.00.log.html | 14:46 |
| ralonsoh | have a nice weekend | 14:46 |
| lajoskatona | o/ | 14:46 |
| amotoki | have a nice weekend! | 14:46 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: ovn: Consider all router ports in is_lsp_router_port() https://review.opendev.org/c/openstack/neutron/+/806424 | 15:12 |
| opendevreview | Merged openstack/ovn-octavia-provider master: Fix race condition retrieving logical router rows https://review.opendev.org/c/openstack/ovn-octavia-provider/+/801517 | 15:50 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: WIP: API tests for BFD support https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/800949 | 16:09 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Write FW OF rules belonging to a port in a single operation https://review.opendev.org/c/openstack/neutron/+/806246 | 17:12 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Remove IDL classes implemented in ovsdbapp https://review.opendev.org/c/openstack/neutron/+/806437 | 17:20 |
| opendevreview | Takashi Kajinami proposed openstack/neutron master: Use importlib instead of imp https://review.opendev.org/c/openstack/neutron/+/804596 | 22:19 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!