| opendevreview | Merged openstack/neutron master: Improve DHCP RPC handler https://review.opendev.org/c/openstack/neutron/+/816850 | 00:23 |
|---|---|---|
| opendevreview | Merged openstack/neutron master: [OVN] Chassis name (OVS system-id) must be a UUID formatted string https://review.opendev.org/c/openstack/neutron/+/819634 | 00:23 |
| opendevreview | Merged openstack/neutron stable/xena: [OVS][FW] Initialize ConjIdMap._max_id depending on the current OFs https://review.opendev.org/c/openstack/neutron/+/819439 | 00:23 |
| opendevreview | Merged openstack/neutron stable/wallaby: [OVS][FW] Initialize ConjIdMap._max_id depending on the current OFs https://review.opendev.org/c/openstack/neutron/+/819440 | 00:23 |
| opendevreview | Merged openstack/neutron stable/victoria: [OVS][FW] Initialize ConjIdMap._max_id depending on the current OFs https://review.opendev.org/c/openstack/neutron/+/819441 | 00:23 |
| opendevreview | Merged openstack/neutron stable/ussuri: [OVS][FW] Initialize ConjIdMap._max_id depending on the current OFs https://review.opendev.org/c/openstack/neutron/+/819442 | 00:23 |
| opendevreview | Takashi Kajinami proposed openstack/neutron stable/wallaby: bw-limit: Pass int parameters to Open vSwitch https://review.opendev.org/c/openstack/neutron/+/820612 | 00:52 |
| opendevreview | Merged openstack/neutron-vpnaas master: Add "update_network" implementation to "L3AgentExtension" child classes https://review.opendev.org/c/openstack/neutron-vpnaas/+/820126 | 02:54 |
| frickler | lajoskatona: slaweq: we talked about this backport last week, please add to your review list https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820099 | 07:58 |
| slaweq | frickler sure | 07:59 |
| slaweq | I will check it right after meeting which I have now | 07:59 |
| lajoskatona | frickler: I will check it | 08:03 |
| slaweq | frickler patch approved | 08:37 |
| opendevreview | Merged openstack/neutron-dynamic-routing stable/xena: Add a StaticScheduler without automatic scheduling https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820099 | 09:11 |
| frickler | slaweq: lajoskatona: thx to both of you, next up will be the backport to wallaby. just in case you thought you were done ;) | 09:12 |
| lajoskatona | frickler: no problem :-) | 09:33 |
| frickler | meh, that gets merge conflicts, no easy-clicky :-( | 09:52 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Keep binding:profile keys during placement allocation change https://review.opendev.org/c/openstack/neutron/+/820363 | 09:53 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/wallaby: Add a StaticScheduler without automatic scheduling https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820680 | 09:56 |
| frickler | luckily 'twas only zuul config | 09:56 |
| *** redrobot8 is now known as redrobot | 10:20 | |
| stephenfin | ralonsoh: I was out on Friday. What did you folks decide on for the '--force'/'--no-force' idea in OSC? | 10:37 |
| ralonsoh | stephenfin, to open a RFE: https://bugs.launchpad.net/neutron/+bug/1953170 | 10:37 |
| ralonsoh | but the proposal was accepted | 10:37 |
| ralonsoh | check the steps in the LP bug. We'll move to --force option in Neutron | 10:37 |
| ralonsoh | (same as Nova) | 10:37 |
| ralonsoh | (of course, that will take a couple of releases) | 10:38 |
| stephenfin | Oh, so you're fixing this in the server rather than the client? | 10:38 |
| ralonsoh | for now we'll keep the current functionality in Neutron | 10:38 |
| ralonsoh | and we'll write a warning message | 10:38 |
| ralonsoh | then we'll change the Neutron server to adopt the Nova behaviour | 10:39 |
| ralonsoh | and then we'll remove the --check-limit parameter | 10:39 |
| ralonsoh | so, for now, the OSC doesn't need any change | 10:39 |
| ralonsoh | that will make Nova and Neutron behaviour more consistent | 10:39 |
| stephenfin | To be clear, I wasn't advocating for changing anything in the server. I was hoping to shim in sensible (IMO) behavior in the client alone | 10:40 |
| stephenfin | Fixing it in the server is definitely a better option long-term but what do we do about the client in the interim | 10:40 |
| stephenfin | ? | 10:40 |
| ralonsoh | in the client nothing, for now | 10:40 |
| ralonsoh | just having --check-limit for Neutron and --force for Nova | 10:40 |
| stephenfin | So we don't add '--check-limit'? | 10:40 |
| ralonsoh | yes, we need it now | 10:40 |
| ralonsoh | then we'll remove it | 10:40 |
| ralonsoh | this is to keep the current behaviour | 10:41 |
| ralonsoh | we don't want to suddenly change the OSC or the Neutron server | 10:41 |
| stephenfin | Agreed. OSC should continue with the "force" (i.e. check_limit=false) behaviour for now. However, do we have to use the '--check-limit' terminology? Could we use '--no-force' instead? | 10:43 |
| stephenfin | Just because the server calls it one thing doesn't mean the client has to use the same terminology | 10:43 |
| ralonsoh | stephenfin, that was agreed in the Neutron drivers meeting | 10:43 |
| ralonsoh | to have this parameter name | 10:44 |
| ralonsoh | in any case, this is temporary | 10:44 |
| stephenfin | example: nova records instance actions, but OSC calls these server actions to be consistent with other server things | 10:44 |
| ralonsoh | Neutron is ok with this term and I'm too | 10:45 |
| ralonsoh | that will survive 2 releases only | 10:45 |
| ralonsoh | and is enough for the customer asking for this feature | 10:45 |
| stephenfin | We can't remove that from OSC once it merges though, because we'll have to support Xena neutron deployments "forever" | 10:46 |
| stephenfin | The '--forces'/'--no-forces' option seems to provide a very nice migration path to a future where neutron behaviour is the same as nova | 10:47 |
| ralonsoh | same as "check-limit" | 10:48 |
| ralonsoh | this is just a parameter name | 10:48 |
| ralonsoh | no-forces == check-limity | 10:48 |
| ralonsoh | I can open again this debate if needed, but really I don't want it | 10:49 |
| ralonsoh | after 3 Neutron drivers meeting trying to explain that I was not going to change the default behaviour | 10:49 |
| stephenfin | Yeah, this is total bike shedding. Sorry :) | 10:50 |
| stephenfin | Okay, I still totally disagree but it's your project and your call :) I'll re-review that today | 10:51 |
| ralonsoh | stephenfin, thanks a lot | 10:51 |
| opendevreview | Maor Blaustein proposed openstack/neutron-tempest-plugin master: Add test_create_port_with_dns_name https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/820456 | 11:29 |
| opendevreview | Maor Blaustein proposed openstack/neutron-tempest-plugin master: Add test_create_port_with_dns_name https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/820456 | 12:00 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Do not announce any DNS resolver if "0.0.0.0" or "::" provided https://review.opendev.org/c/openstack/neutron/+/820858 | 12:31 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Add tap-as-a-service scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/814876 | 12:33 |
| noonedeadpunk | hey there! I'm wondering if there's some known issue present for neutron-server served as uwsgi and ovn? | 12:40 |
| ralonsoh | noonedeadpunk, there is, uwsgi is still not supported | 12:40 |
| noonedeadpunk | ah! I jsut thought that since you test it in CI it does hehe | 12:41 |
| noonedeadpunk | feels like neutron left as close to the only one service left... | 12:44 |
| slaweq | noonedeadpunk there is one bug https://bugs.launchpad.net/neutron/+bug/1912359 which blocks it | 13:05 |
| noonedeadpunk | well, what we see that uwsgi responds at first, but then got stuck and stop replying on requests... | 13:08 |
| noonedeadpunk | but yeah, sounds like we see that as well in osa | 13:08 |
| noonedeadpunk | except that there's probably some issue with calico driver as well... | 13:09 |
| noonedeadpunk | but it's quite different topic indeed | 13:09 |
| ricolin | lajoskatona, FYI, Pain point discussion meeting have scheduled on 1500UTC this Wednesday(Dec. 8th) in https://meet.google.com/xsx-inbw-mos | 13:45 |
| lajoskatona | ricolin: thanks, I added to my calendar :-) | 13:46 |
| lajoskatona | #startmeeting networking | 14:00 |
| opendevmeet | Meeting started Tue Dec 7 14:00:58 2021 UTC and is due to finish in 60 minutes. The chair is lajoskatona. 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 'networking' | 14:00 |
| mlavalle | o/ | 14:01 |
| lajoskatona | Hi | 14:01 |
| slaweq | hi | 14:01 |
| ralonsoh | hi | 14:01 |
| lajoskatona | I think we can start | 14:02 |
| bcafarel | o/ | 14:02 |
| obondarev | hi | 14:02 |
| lajoskatona | #topic Announcements | 14:02 |
| mlavalle | with bcafarel and obondarev we have completed the ususal suspects bunch for this meeting | 14:02 |
| lajoskatona | mlavalle: exactly | 14:03 |
| lajoskatona | The usual cycle calendar: https://releases.openstack.org/yoga/schedule.html | 14:03 |
| lajoskatona | This is Week R-16: http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026173.html | 14:03 |
| rubasov | o/ | 14:04 |
| lajoskatona | I think we should cut new release for n-lib at least (have to check other libs if we have enough things merged | 14:05 |
| slaweq | for neutron-lib I think we are ok as we already released it this cycle | 14:06 |
| slaweq | same for os-ken iirc | 14:06 |
| slaweq | I'm not sure about ovsdbapp | 14:06 |
| slaweq | but of course we can release new versions around X-2 milestone | 14:06 |
| opendevreview | Merged openstack/neutron stable/xena: [OVN] Fix gateway_mtu option should not always be set https://review.opendev.org/c/openstack/neutron/+/819578 | 14:07 |
| lajoskatona | for neutron-lib just for the regularity we should have one, and last time it was this group we waited for: https://review.opendev.org/q/topic:%2522bug/1950454%2522+(status:open+OR+status:merged)+update_network | 14:07 |
| opendevreview | Merged openstack/neutron stable/wallaby: [OVN] Fix gateway_mtu option should not always be set https://review.opendev.org/c/openstack/neutron/+/819579 | 14:07 |
| lajoskatona | slaweq: thanks | 14:07 |
| lajoskatona | Some news for the testing runtime: | 14:08 |
| lajoskatona | full discussion: http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026175.html | 14:08 |
| lajoskatona | and the summary from last week TCmeeting: "We have an agreement now on Yoga testing runtime and keeping python3.6 support in Yoga." | 14:08 |
| lajoskatona | so we keep py36 in this cycle | 14:09 |
| slaweq | ++ | 14:10 |
| lajoskatona | another announcement: "Pain Points" discussion continues: http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026169.html | 14:10 |
| lajoskatona | There's an etherpad: https://etherpad.opendev.org/p/pain-point-elimination | 14:11 |
| lajoskatona | and there will be a meeting: Dec. 8th, 15:00 UTC | 14:11 |
| lajoskatona | As I see OSC is the main pain point, and we are on the good side | 14:12 |
| slaweq | lajoskatona do You know if tomorrow it will be discussion about Neutron maybe? | 14:12 |
| slaweq | I'm not sure if I should join there or maybe it's not needed at all | 14:12 |
| lajoskatona | slaweq: it will be openstack wide if I understand well | 14:12 |
| slaweq | ok | 14:13 |
| slaweq | I will try to be there | 14:13 |
| mlavalle | yeah, looking at the email, it is not specific to Neutron | 14:13 |
| lajoskatona | I can join tomorrow | 14:13 |
| amotoki | lajoskatona: where does it happen? | 14:14 |
| mlavalle | It's a video conference | 14:14 |
| lajoskatona | in the etherpad there are a few neutron related things (hostname, osc/neutronclient compatibility) | 14:14 |
| amotoki | I don't see the URL for it | 14:14 |
| lajoskatona | amotoki: #link https://meet.google.com/xsx-inbw-mos | 14:14 |
| amotoki | lajoskatona: thanks. I also found the link in the mailing list thread | 14:15 |
| lajoskatona | so I have hopes that not Neutron will be the bad guy :-) | 14:15 |
| slaweq | lajoskatona it's always networking issue so it will be ;P | 14:16 |
| lajoskatona | slaweq: that's true :-) | 14:16 |
| bcafarel | :) | 14:16 |
| amotoki | everyone talks over networks :) | 14:16 |
| mlavalle | poor Neutron guys, they are always blamed | 14:17 |
| slaweq | LOL | 14:17 |
| lajoskatona | Any comments for announcements? | 14:17 |
| lajoskatona | #topic Bugs | 14:18 |
| lajoskatona | lajoskatona (it's me :-)) was bug deputy last week: http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026193.html | 14:18 |
| lajoskatona | We have 3 unassigned bugs: | 14:19 |
| lajoskatona | #link https://bugs.launchpad.net/neutron/+bug/1952675 | 14:19 |
| lajoskatona | this one is about a db upgrade issue | 14:19 |
| lajoskatona | #link https://bugs.launchpad.net/neutron/+bug/1944779 | 14:20 |
| lajoskatona | This one is tough: VirtualInterfaceCreateException due to "Timeout waiting for [('network-vif-plugged'..." | 14:20 |
| lajoskatona | As I remember there was a long mail thread for this | 14:20 |
| lajoskatona | I think this mail started it: #link http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025892.html | 14:21 |
| ralonsoh | there are several mixed discussions there | 14:21 |
| ralonsoh | including several backend types | 14:21 |
| ralonsoh | so when investigating those kind of errors, focus on one backend | 14:22 |
| lajoskatona | from nova perspective that is one of the problems that nova has to act based on network backend and that is not elegant, as I remember | 14:23 |
| slaweq | yes, and the problem is that it behaves differently in each neutron backend :/ | 14:24 |
| lajoskatona | I mean that nova has to use big if-else blocks to wait or not wait for event based on something that is Neutron internal thing | 14:24 |
| lajoskatona | slaweq: exactly | 14:24 |
| lajoskatona | I think in our downstream CI the issue was that odl and ovs send vif-pluged differently for example | 14:25 |
| lajoskatona | so ti was hard to debug even what happens or not happens | 14:25 |
| lajoskatona | ok we had another unassigned bug from last week: #link https://bugs.launchpad.net/neutron/+bug/1953165 | 14:27 |
| lajoskatona | and actually rubasov started to check it | 14:27 |
| rubasov | it may be a duplicate of https://bugs.launchpad.net/neutron/+bug/1930414 | 14:28 |
| lajoskatona | rubasov: thanks, I was looking for this | 14:29 |
| slaweq | rubasov so do You think we are leaking IPv6 traffic between isolated networks? | 14:29 |
| haleyb | I would also guess it's possible that there is a second namespace with that IPv6 address, like the qrouter | 14:29 |
| rubasov | yes I believe so | 14:29 |
| haleyb | rubasov: oh, that would be worse :( | 14:29 |
| rubasov | I think it's only a short window when ports belong to the DEAD_VLAN | 14:30 |
| rubasov | I'll update that bug report soon | 14:31 |
| slaweq | but priteau said there that even after restarting neutron-dhcp-agent it wasn't fixed in many cases | 14:31 |
| slaweq | shouldn't that dead vlan tag be already removed in such case? | 14:32 |
| mlavalle | good point | 14:32 |
| rubasov | slaweq: nobody will clear dadfailed state | 14:32 |
| slaweq | rubasov ahh, ok | 14:32 |
| rubasov | so if dadfailed happens during the short windows it stays | 14:32 |
| slaweq | dhcp agent will just check that interface is there and will do nothing with it after restart | 14:33 |
| rubasov | I also have a patch, which I'll upload, but that's at most a partial fix and not fixing the full root cause which I still don't get | 14:33 |
| priteau | (I am here in case you need further details) | 14:34 |
| rubasov | priteau: feel free to try the reproduction in bug 1930414 to see if it's the same as you see | 14:35 |
| rubasov | priteau: also after the update I'll add soon | 14:35 |
| priteau | I started setting up a dev environment to try and reproduce it. So far I've only seen it on a prod system | 14:36 |
| lajoskatona | thanks rubasov for the explanation and for working on this issue | 14:38 |
| lajoskatona | This week amotoki is the deputy, and next week mlavalle will be. | 14:39 |
| mlavalle | ack | 14:39 |
| amotoki | ack | 14:39 |
| mlavalle | Thanks for the reminder | 14:39 |
| lajoskatona | cool | 14:39 |
| mlavalle | I still require a formal email.... | 14:39 |
| lajoskatona | mlavalle: I just wanted to ask :-) | 14:39 |
| mlavalle | no, just kdding. slaweq spoiled me | 14:39 |
| slaweq | LOL | 14:40 |
| lajoskatona | advertisement: slaweq prepared something for the "reduce rechecks" topic: http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026208.html | 14:41 |
| lajoskatona | so if you have ideas, or interested join please to the CI meeting from 15:00 UTC :-) | 14:41 |
| slaweq | ++ | 14:42 |
| slaweq | anyone's welcome there | 14:42 |
| lajoskatona | thanks slaweq | 14:43 |
| lajoskatona | we have nothing for L3, and no changes in ryu | 14:43 |
| lajoskatona | #topic On Demand Agenda | 14:43 |
| opendevreview | Merged openstack/neutron stable/victoria: [OVN] Fix gateway_mtu option should not always be set https://review.opendev.org/c/openstack/neutron/+/819580 | 14:44 |
| lajoskatona | If there is nothing to discuss, let's close the meeting | 14:45 |
| mlavalle | sounds good to me | 14:45 |
| lajoskatona | #endmeeting | 14:45 |
| opendevmeet | Meeting ended Tue Dec 7 14:45:31 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:45 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2021/networking.2021-12-07-14.00.html | 14:45 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2021/networking.2021-12-07-14.00.txt | 14:45 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2021/networking.2021-12-07-14.00.log.html | 14:45 |
| slaweq | ++ | 14:45 |
| mlavalle | o/ | 14:45 |
| lajoskatona | o/ | 14:45 |
| bcafarel | o/ | 14:45 |
| slaweq | see You in 15 minutes on the ci meeting :) | 14:45 |
| ralonsoh | bye | 14:45 |
| amotoki | o/ | 14:45 |
| slaweq | #startmeeting neutron_ci | 15:00 |
| opendevmeet | Meeting started Tue Dec 7 15:00:15 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'neutron_ci' | 15:00 |
| slaweq | Grafana dashboard: http://grafana.openstack.org/dashboard/db/neutron-failure-rate | 15:00 |
| slaweq | video meeting link https://meetpad.opendev.org/neutron-ci-meetings | 15:00 |
| bcafarel | o/ joining in a min | 15:02 |
| opendevreview | Bence Romsics proposed openstack/neutron master: WIP sleep to raise the chance of crosstalk between dhcp ports https://review.opendev.org/c/openstack/neutron/+/820896 | 15:02 |
| opendevreview | Bence Romsics proposed openstack/neutron master: A step toward making the dead vlan actually dead https://review.opendev.org/c/openstack/neutron/+/820897 | 15:02 |
| slaweq | #topic Actions from previous meetings | 15:03 |
| slaweq | lajoskatona to check why make FIP down took more than 120 seconds in the L3 agent | 15:03 |
| opendevreview | Bence Romsics proposed openstack/neutron master: A step toward making the dead vlan actually dead https://review.opendev.org/c/openstack/neutron/+/820897 | 15:03 |
| slaweq | slaweq to check failed neutron.tests.functional.agent.l3.test_keepalived_state_change.TestMonitorDaemon.test_handle_initial_state_backup | 15:07 |
| slaweq | lajoskatona to increase timeout of the lower-constraints job in neutron | 15:09 |
| haleyb | otherwiseguy: can you take a look at https://bugs.launchpad.net/neutron/+bug/1953481 seems liks ovsdbapp bug (sorry to interrupt meeting) | 15:10 |
| slaweq | slaweq to check https://7bed286b1abc124aef60-716c2febf7f730d66787c22f3ed0da3e.ssl.cf5.rackcdn.com/818067/2/check/neutron-functional-with-uwsgi/48adb0f/testr_results.html | 15:11 |
| slaweq | slaweq to report bug about failing neutron_tempest_plugin.scenario.test_mac_learning.MacLearningTest | 15:12 |
| slaweq | Done https://bugs.launchpad.net/neutron/+bug/1952066 | 15:12 |
| slaweq | #topic Stable branches | 15:13 |
| slaweq | #topic Stadium projects | 15:14 |
| slaweq | #topic Grafana | 15:15 |
| slaweq | #action slaweq to check missing grafana logs for periodic jobs | 15:16 |
| bcafarel | ykarel: testing grafana dashboards locally https://blog.cafarelli.fr/2016/12/local-testing-of-openstack-grafana-dashboard-changes/ (not sure if it still works) | 15:18 |
| ykarel | bcafarel, Thanks /me will tryout some time | 15:18 |
| ykarel | ohh 2016, so will likely not work as it is | 15:19 |
| ykarel | but worth a try | 15:19 |
| bcafarel | hopefully a few URLs updates (and maybe grafana being easier to install now) and the rest may still be OK | 15:20 |
| slaweq | #topic Tempest/Scenario | 15:21 |
| slaweq | #link https://bugs.launchpad.net/nova/+bug/1953478 | 15:21 |
| slaweq | #link https://bugs.launchpad.net/neutron/+bug/1953479 | 15:23 |
| slaweq | #link https://bugs.launchpad.net/neutron/+bug/1953480 | 15:25 |
| slaweq | #link https://565740c969459684c3b5-240d4aa44573f96d2050363ab0d496a6.ssl.cf2.rackcdn.com/820125/1/check/neutron-ovs-tempest-dvr-ha-multinode-full/d90c2a6/testr_results.html | 15:27 |
| slaweq | #link https://launchpad.net/bugs/1813787 | 15:27 |
| slaweq | #topic Periodic | 15:30 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1953481 | 15:30 |
| slaweq | #action ralonsoh to check https://bugs.launchpad.net/neutron/+bug/1953481 | 15:32 |
| slaweq | #topic On Demand | 15:32 |
| slaweq | https://etherpad.opendev.org/p/neutron-ci-improvements | 15:32 |
| slaweq | #link https://etherpad.opendev.org/p/neutron-ci-improvements | 15:33 |
| lajoskatona | for retry: https://opendev.org/zuul/zuul/src/branch/master/doc/source/reference/jobs.rst#build_status | 15:47 |
| lajoskatona | "The pre-run playbook failed more than the maximum number of retry attempts." | 15:47 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/wallaby: Add a StaticScheduler without automatic scheduling https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820680 | 15:50 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/wallaby: Dropping lower constraints testing (stable Wallaby) https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820908 | 15:50 |
| gibi | http://status.openstack.org/elastic-recheck/ | 15:56 |
| gibi | and you have to propose query signature here https://opendev.org/opendev/elastic-recheck/src/branch/master/queries | 16:01 |
| otherwiseguy | haleyb: on PTO until Jan 4 | 16:05 |
| slaweq | #endmeeting | 16:06 |
| opendevmeet | Meeting ended Tue Dec 7 16:06:01 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:06 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-12-07-15.00.html | 16:06 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-12-07-15.00.txt | 16:06 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-12-07-15.00.log.html | 16:06 |
| slaweq | thx gibi for the links | 16:06 |
| haleyb | otherwiseguy: ack, I heard, will ping jlibosva or ralonsoh to look at bug since they +2'd it | 16:06 |
| ralonsoh | haleyb, I'm on it now | 16:07 |
| slaweq | thx gibi for the links | 16:07 |
| haleyb | ralonsoh: ack, i'll stop looking then | 16:08 |
| otherwiseguy | haleyb: looks like I get to have another reason to hate Mocking :D | 16:09 |
| haleyb | otherwiseguy: yeah... i was trying to figure out if it was just the test or things could have been made compatible in ovsdbapp somehow. but enjoy your PTO :) | 16:11 |
| otherwiseguy | haleyb: ralonsoh: I'd be surprised if there is anything to do in ovsdbapp. It's just that the mock.Mock() has no 'priority'. making it a magicmock will probably fix. | 16:18 |
| otherwiseguy | jlibosva had suggested having _get_queue take a priority and not an event, which also probably would have avoided the issue. | 16:19 |
| otherwiseguy | jlibosva is always right though, one day I'll learn to just do what he says. :D | 16:19 |
| otherwiseguy | I believe his reasoning was even "it'd make it easier to test" :D | 16:20 |
| otherwiseguy | though I guess you'd have to get the priority anyway, so meh. anyway, I'm going to go back to wasting my with housework. :D | 16:25 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: WIP: Make ovs-taas start in VLAN only env https://review.opendev.org/c/openstack/tap-as-a-service/+/817449 | 16:42 |
| * jlibosva reads | 16:43 | |
| * jlibosva knows a person with otherwiseguy nick but he should be on PTO | 16:44 | |
| *** otherwiseguy is now known as not_otherwiseguy | 16:44 | |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: WIP: Make ovs-taas start in VLAN only env https://review.opendev.org/c/openstack/tap-as-a-service/+/817449 | 16:45 |
| not_otherwiseguy | jlibosva: tl;dr s/mock.Mock/mock.MagicMock/ | 16:45 |
| jlibosva | not_otherwiseguy: ah, I see now. the priority parameter :D | 16:45 |
| haleyb | not_otherwiseguy: that doesn't work directly unfortunately, assertCountEqual failure | 16:46 |
| jlibosva | haleyb: ralonsoh is there anything I can help with wrt ovsdbapp bug? are you gonna send the MagicMock patch? | 16:51 |
| ralonsoh | jlibosva, I have one ready | 16:51 |
| ralonsoh | give me 30 secs | 16:51 |
| jlibosva | 29 | 16:51 |
| jlibosva | 28 | 16:51 |
| jlibosva | 27 | 16:51 |
| ralonsoh | heheh | 16:51 |
| not_otherwiseguy | haleyb: ah, yeah, can't look at _watched_events :) | 16:57 |
| not_otherwiseguy | IT'S SECRET | 16:57 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Mock the OVN events providing a "priority" value https://review.opendev.org/c/openstack/neutron/+/820911 | 17:00 |
| ralonsoh | jlibosva, ^^ | 17:01 |
| * haleyb throws-up in his mouth a little looking :) | 17:02 | |
| not_otherwiseguy | ralonsoh: Mine was similar :D https://paste.centos.org/view/6cdd04f4 | 17:06 |
| not_otherwiseguy | But I'm definitely not working. | 17:07 |
| * not_otherwiseguy hides | 17:07 | |
| * not_otherwiseguy remembers he is not_otherwiseugy so can work | 17:07 | |
| not_otherwiseguy | ralonsoh: haleyb: jlibosva: I guess if we had to we could do in _get_event a getattr(event, 'priority', 0) | 17:23 |
| not_otherwiseguy | just to make things work regardless. | 17:24 |
| ralonsoh | what is the highest priority? 0? | 17:24 |
| not_otherwiseguy | -infinity is lowest priority (i.e. will execute last) | 17:25 |
| ralonsoh | by default we should assign the lowest one | 17:25 |
| ralonsoh | 0 is the maximum | 17:25 |
| ralonsoh | or do you consider that, if no priority is given, that means this is a high priority event? | 17:26 |
| ralonsoh | just asking | 17:27 |
| ralonsoh | if so, I'm ok | 17:27 |
| not_otherwiseguy | 0 is not the maximum. | 17:27 |
| ralonsoh | ok, you can provide negative values | 17:27 |
| not_otherwiseguy | and the sort order is reversed. | 17:27 |
| not_otherwiseguy | WaitEvent has a priority of 10, it goes after RowEvent which has a priority of 20. | 17:28 |
| not_otherwiseguy | sort function is negative priority, i.e. highest numbers highest priority. | 17:29 |
| not_otherwiseguy | but in any case, you really have to pass in a subclass of RowEvent, and RowEvent defaults to priority=20 so meh. it's just testing that would not have a priority. | 17:32 |
| not_otherwiseguy | eh, getattr doesn't actually fix it anyway | 17:35 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: test_list_agent: pop 'alive' from agent dict https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/820921 | 17:46 |
| not_otherwiseguy | (because mock is evil) :p | 17:47 |
| *** not_otherwiseguy is now known as otherwiseguy | 17:48 | |
| * otherwiseguy goes back to PTOing | 17:48 | |
| *** jlibosva is now known as Guest7885 | 19:55 | |
| opendevreview | Merged openstack/neutron-tempest-plugin master: [stable/rocky] Regroup tests exclusion list and add new failing ones https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/819109 | 20:33 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!