opendevreview | Jimin Shin proposed openstack/neutron master: Duplicated table lookup in extending port resource request https://review.opendev.org/c/openstack/neutron/+/944650 | 00:45 |
---|---|---|
opendevreview | Jimin Shin proposed openstack/neutron master: Extend port resource request when not using qos minimum rules https://review.opendev.org/c/openstack/neutron/+/944756 | 00:46 |
opendevreview | Jimin Shin proposed openstack/neutron master: Extend port resource request only when using qos minimum rules https://review.opendev.org/c/openstack/neutron/+/944756 | 01:55 |
opendevreview | Jimin Shin proposed openstack/neutron master: Check resource_request is required https://review.opendev.org/c/openstack/neutron/+/944756 | 02:01 |
opendevreview | OpenStack Proposal Bot proposed openstack/neutron master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron/+/944822 | 03:39 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Revert "[eventlet-removal] Remove the usage of eventlet in the DHCP agent" https://review.opendev.org/c/openstack/neutron/+/944634 | 06:55 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Revert "[eventlet-removal] Remove eventlet from DHCP agent" https://review.opendev.org/c/openstack/neutron/+/944826 | 06:56 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Revert "[eventlet-removal] Remove eventlet from DHCP agent" https://review.opendev.org/c/openstack/neutron/+/944826 | 06:56 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Delete a resource provider removed from the agent config https://review.opendev.org/c/openstack/neutron/+/944053 | 07:01 |
mnasiadka | ralonsoh: if you need anything from Kolla for 944763 - let me know - we would be happy if this could be merged today | 07:02 |
ralonsoh | mnasiadka, I didn't see the execution yesterday. I thought the exiting results were all, my bad | 07:05 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Make the Logical_Switch_Port UP event more robust https://review.opendev.org/c/openstack/neutron/+/943404 | 07:11 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: DNM == Test "neutron-tempest-plugin-openvswitch" https://review.opendev.org/c/openstack/neutron/+/942615 | 07:39 |
mnasiadka | ralonsoh: I think all projects have a separate aarch64 pipeline | 07:59 |
danfai | hi neutron, is there a way to speed up neutron-ovn-db-sync-util? While doing an initial sync we take like 2 seconds per port for adding it | 09:56 |
ralonsoh | danfai, what version are you using? a logical_switch_port are you saying? | 09:59 |
danfai | ralonsoh: we are in yoga, OVN 22.12 ; It currently is in the loop for the lsp, yes | 10:00 |
ralonsoh | danfai, yoga is a very old release no longer supported | 10:00 |
ralonsoh | the last supported version is 2023.2, 3 releases newer | 10:00 |
danfai | ok, I'll have a look whether there were changes to speed this up, but I fear this will be a huge pain point when migrating from Lxb to OVN, since you will have to sync initially. In our case this is 8h+ on 15k ports | 10:01 |
danfai | especially since ports that are being deleted in neutron during the initial sync, we will have to restart the job | 10:02 |
danfai | (they fail, since the revision number cannot be updated) | 10:02 |
ralonsoh | danfai, but what section is the affected one? | 10:03 |
ralonsoh | where exactly it takes so much time? | 10:03 |
ralonsoh | where the Neutron ports are deleted?? | 10:03 |
danfai | we should be in that loop https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_db_sync.py#L1176 | 10:04 |
danfai | the ports being deleted is because we have the API still up and jobs running in the meantime. Since there mostly should not be any changes being done on the neutron DB, this should be a safe operation for us | 10:05 |
opendevreview | Merged openstack/neutron stable/2023.2: Fast exit if "segments" plugin is not loaded https://review.opendev.org/c/openstack/neutron/+/944399 | 10:06 |
opendevreview | Merged openstack/neutron stable/2024.1: Fast exit if "segments" plugin is not loaded https://review.opendev.org/c/openstack/neutron/+/944398 | 10:06 |
opendevreview | Merged openstack/neutron stable/2024.2: Fast exit if "segments" plugin is not loaded https://review.opendev.org/c/openstack/neutron/+/944397 | 10:06 |
ralonsoh | danfai, I don't remember where this is documented but the environment should not be loaded during the sync process | 10:07 |
ralonsoh | so any work should be stopped and the Neutron API dedicated only to the sync | 10:07 |
danfai | So do you think it would be safe to run the sync-util on a clone of the DB for example? | 10:08 |
ralonsoh | danfai, why on a clone? you need to execute the sync in the environment because it makes changes in the Neutron and OVN databases | 10:10 |
danfai | because there is no way we can afford an 8h+ downtime | 10:10 |
opendevreview | Pierre Riteau proposed openstack/neutron master: Spawn IPv6 metadata proxy only when required https://review.opendev.org/c/openstack/neutron/+/944763 | 10:20 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Isolate ``test_ovsdb_monitor.TestNBDbMonitor*`` FTs https://review.opendev.org/c/openstack/neutron/+/944858 | 11:04 |
ralonsoh | ykarel, if you have 1 min ^^ | 11:04 |
ykarel | ralonsoh, don't we also need to move these to mysql as those were reporting sqlite Foreign constraint errors? | 11:07 |
ralonsoh | ykarel, sorry what test cases? I thought this was the affected class | 11:09 |
ralonsoh | ahhhh | 11:09 |
ralonsoh | ok ok ok | 11:09 |
ralonsoh | understood | 11:10 |
ykarel | https://ac967958d7db9925bf11-8258bbe2bfc0c508066a865a71f46e18.ssl.cf1.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron-functional/ed0c42a/testr_results.html | 11:10 |
ralonsoh | yeah, I'll it too | 11:10 |
ralonsoh | I'll do it too* | 11:10 |
ykarel | ack | 11:11 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN][FT] Use MySQL backend for ``TestNBDbMonitor*`` classes https://review.opendev.org/c/openstack/neutron/+/944860 | 11:15 |
zigo | A customer of us has set 68 as MTU in his network on our public cloud. Result: neutron-dhcp-agent stack traces in loop... | 11:32 |
zigo | So it would be good if it could at least be not allowed in the Neutron policy. | 11:32 |
zigo | ralonsoh: Your thoughts? :) | 11:32 |
ralonsoh | no, that was already commented | 11:32 |
ralonsoh | we have a document about the MTU min values | 11:32 |
ralonsoh | but this is up to the user to set the correct value | 11:32 |
ralonsoh | I don't remember when that was discussed, let me check | 11:33 |
zigo | That'd be ok if at least the agent was not stack-tracing in loop and filling-up its log file. | 11:33 |
zigo | I saw this bug opened: https://bugs.launchpad.net/neutron/+bug/1988069 | 11:33 |
ralonsoh | so we finally implemented a cap... | 11:35 |
ralonsoh | https://review.opendev.org/c/openstack/neutron/+/875809/8/neutron/db/db_base_plugin_v2.py | 11:35 |
ralonsoh | ok, so the problem you are mentioning should not happen then | 11:35 |
zigo | Oh, thanks a lot. | 11:37 |
zigo | So that patch limits the MTU minimum, right? | 11:37 |
zigo | I'll backport it and deploy it then. | 11:37 |
ralonsoh | zigo, this is an API change | 11:38 |
ralonsoh | we don't support this kind of backports | 11:38 |
ralonsoh | in U/S, maybe you are talking about your own repo | 11:38 |
zigo | Right. | 11:39 |
zigo | Though now, I see the IPV4_MIN_MTU in that patch is set to 68 for IPv4. | 11:40 |
opendevreview | Lajos Katona proposed openstack/neutron master: If OVS Manager creation failes retry to set values https://review.opendev.org/c/openstack/neutron/+/939117 | 11:40 |
zigo | Well, that's still would allow neutron-dhcp-agent to crash then! | 11:40 |
zigo | I'm tempted to backport that patch, and artificially set IPV4_MIN_MTU to 1300 ... | 11:41 |
ralonsoh | what is the error in the DHCP agent? | 11:41 |
zigo | (ie: as Debian specific patch) | 11:41 |
zigo | Hang on, sending log entry (need to anonymize ...) | 11:42 |
zigo | https://paste.opendev.org/show/b2VHDYtqMid27ksMx1H5/ | 11:46 |
zigo | (replaced UUIDs and tap names...) | 11:46 |
ralonsoh | ok, I'll check it now | 11:47 |
zigo | We got 1500+ entry like that one per hour, for just *one* badly configured customer network. | 11:48 |
zigo | FYI, that's a Caracal setup. | 11:48 |
zigo | I've forced 1500 on the customer's network MTU, plus asked our support to contact the customer so that they don't do that again, but obviously that's not a long term solution. | 11:49 |
ralonsoh | zigo, do you happen to know what are the values passed in the call "rv = getattr(driver, action)(**action_kwargs)" | 11:52 |
zigo | I don't. :/ | 11:52 |
zigo | that's a production cloud, I can't play with it too much. | 11:52 |
ralonsoh | zigo, does this network have multiple subnets? | 11:53 |
zigo | Though it should be fairly easy to reproduce. (would take my CI about 3 or 4 hours to run though). | 11:53 |
zigo | Checking... | 11:53 |
zigo | A single 10.0.0.0/24 subnet. | 11:54 |
ralonsoh | ok, I'll try to reproduce it locally | 11:55 |
zigo | Cheers. | 11:56 |
sahid | haleyb: o/ | 13:08 |
sahid | regarding https://review.opendev.org/c/openstack/neutron/+/940983 | 13:08 |
sahid | I'm not toally sure we should use context manager here, can you just confirm with me it is the direction you really want to take? | 13:08 |
mnasiadka | ralonsoh: sorry for chasing, any chance to get another review on https://review.opendev.org/c/openstack/neutron/+/944763 ? | 13:19 |
opendevreview | Candido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: Increase burst window size to avoid unstabilities in slow envs https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/944616 | 13:33 |
ralonsoh | mnasiadka, sure | 13:46 |
ralonsoh | mnasiadka, https://review.opendev.org/c/openstack/neutron/+/944763/3/neutron/agent/dhcp/agent.py#788 this comment is legit | 13:47 |
ralonsoh | you can break after assigning need_ipv6_metadata | 13:47 |
ralonsoh | mnasiadka, if you respin the patch fixing it, I'll +2 intermediately | 13:51 |
ralonsoh | and we'll backport it ASAP | 13:51 |
haleyb | mnasiadka: i just commented in that patch as well, we should fix since it will be backported. i can do it quickly if you like | 13:58 |
ralonsoh | "I'll +2 intermediately"... pffff I don't read what I write... | 13:59 |
haleyb | ralonsoh: i read it "correctly" :) | 14:00 |
haleyb | #startmeeting networking | 14:00 |
opendevmeet | Meeting started Tue Mar 18 14:00:23 2025 UTC and is due to finish in 60 minutes. The chair is haleyb. 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 |
haleyb | Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh | 14:00 |
haleyb | o/ | 14:00 |
obondarev | o/ | 14:00 |
slaweq | o/ | 14:00 |
ralonsoh | hello | 14:00 |
bcafarel | o/ | 14:00 |
mlavalle | \o | 14:00 |
rubasov | o/ | 14:01 |
haleyb | #announcements | 14:01 |
lajoskatona | o/ | 14:01 |
haleyb | We are currently in week R-2 of Epoxy | 14:01 |
haleyb | RC1 was tagged and stable/2025.1 branch created | 14:01 |
haleyb | so anything critical should be cherry-picked to get into RC2 | 14:02 |
haleyb | i know there is the IPv6 metadata one | 14:02 |
ralonsoh | the dhcp eventlet removal | 14:03 |
ralonsoh | https://review.opendev.org/c/openstack/neutron/+/944826/2 | 14:03 |
haleyb | Final RC deadline: March 28th, 2025 (R-1 week) | 14:03 |
haleyb | ralonsoh: oh, the revert | 14:04 |
ralonsoh | yes, both patches | 14:04 |
ralonsoh | must be in 2025.1 too | 14:04 |
lajoskatona | +1 | 14:04 |
haleyb | glad we figured that out | 14:05 |
lajoskatona | after half openstack collapsed, but in time anyway :-) | 14:05 |
haleyb | https://review.opendev.org/c/openstack/neutron/+/944634/2 is the parent change, got it | 14:06 |
haleyb | Final 2025.1 Epoxy release: April 2nd, 2025 | 14:06 |
haleyb | So please ping people here if you need reviews on critical gate fixes, and/or get them on the priority board | 14:07 |
haleyb | Project Teams Gathering (virtual): April 7th-11th, 2025 | 14:08 |
haleyb | #link https://ptg.openinfra.dev/ to sign up | 14:08 |
haleyb | #link https://etherpad.opendev.org/p/apr2025-ptg-neutron | 14:08 |
haleyb | #link https://ptg.opendev.org/ptg.html for room assignments | 14:08 |
haleyb | I added two slots Tuesday, 4 on Wednesday and Thursday | 14:09 |
haleyb | did not want to conflict with eventlet | 14:09 |
haleyb | please add topics to the etherpad, think we should just push all RFE discussions until then | 14:10 |
haleyb | that was all i had for announcements today, any others? | 14:11 |
lajoskatona | thanks for PTG management :-) | 14:11 |
haleyb | that's what you pay me for, oh wait... :) | 14:12 |
sahid | o/ late | 14:12 |
haleyb | o/ | 14:12 |
haleyb | #topic bugs | 14:12 |
haleyb | mlavalle was deputy last week, report is at | 14:12 |
mlavalle | \o | 14:12 |
haleyb | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/UA5Q7RUKIIWHZLYIEERYHB4T5NQANEPP/ | 14:12 |
haleyb | so the high have been addressed | 14:14 |
haleyb | and the dhcp one is in flight | 14:14 |
haleyb | #link https://bugs.launchpad.net/neutron/+bug/2101871 | 14:15 |
haleyb | Use of revision_number for router update on 2023.2 Bobcat cause error 500 | 14:15 |
haleyb | that was an interesting one, still waiting for the commands to reproduce | 14:15 |
mlavalle | we are waiting for a response from submitter | 14:15 |
haleyb | and this one is incomplete as well | 14:16 |
haleyb | #link https://bugs.launchpad.net/neutron/+bug/2102044 | 14:16 |
haleyb | Nova-API problem - cannot list instances anymore | 14:16 |
haleyb | might be config, i'm assuming it's not packages | 14:16 |
ralonsoh | but do we have the Neutron APi exception? | 14:18 |
haleyb | ralonsoh: no he never pasted it | 14:18 |
ralonsoh | ok, we need it, for sure | 14:18 |
haleyb | yes. i'm watching as i want to make sure it's not a distro problem since it was ubuntu, but don't think it is | 14:18 |
haleyb | i did start seeing random batch_notifier unit test failures, one was in the metadata patch | 14:19 |
haleyb | #link https://bugs.launchpad.net/neutron/+bug/2100806 | 14:19 |
haleyb | saw them again i meant to say | 14:19 |
haleyb | ralonsoh: can you see my comment in https://review.opendev.org/c/openstack/neutron/+/943212 ? maybe we can discuss after meeting | 14:20 |
ralonsoh | sure | 14:20 |
opendevreview | Candido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: Increase burst window size to avoid unstabilities in slow envs https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/944616 | 14:20 |
haleyb | any other bugs to discuss? | 14:21 |
ralonsoh | yes, two | 14:21 |
haleyb | sure | 14:21 |
ralonsoh | https://bugs.launchpad.net/neutron/+bug/2102090 | 14:21 |
ralonsoh | I initially set it as low and no RFE | 14:22 |
ralonsoh | because that could be a bug, not a RFE | 14:22 |
ralonsoh | the problem: with eventlet module, all workers (API, maintenance, rpc, periodic) were executed in the same process | 14:22 |
ralonsoh | now this is not happening, but the OVN placement initial config is in the maintenance worker | 14:23 |
ralonsoh | but anyone will expect that, if you restart the Neutron API, that will be executed | 14:23 |
ralonsoh | so the question is: should we move this to the Neutron API code? | 14:23 |
ralonsoh | now, if we want to re-execute this initial config, we need to restart the maintenance process | 14:24 |
haleyb | ralonsoh: it seems it was almost an unintended change and should be fixed | 14:25 |
ralonsoh | perfect, I had the same idea | 14:25 |
ralonsoh | this is why I opened the bug | 14:25 |
ralonsoh | anyone else if free to comment on the LP bug, if needed | 14:26 |
ralonsoh | the second one: | 14:26 |
ralonsoh | this is the upper patch: https://review.opendev.org/c/openstack/neutron/+/944053 | 14:26 |
ralonsoh | it needs to be backported | 14:26 |
ralonsoh | but the first patch (singleton one) could be intrusive | 14:26 |
ralonsoh | I implemented that for the tests, but I can re-implement the tests for stable branches without it | 14:27 |
ralonsoh | so please, review these patches and I'll backport them (2nd and 3rd patch) without the 1st one | 14:27 |
ralonsoh | that's all | 14:27 |
frickler | about https://review.opendev.org/c/openstack/neutron/+/944763 / https://launchpad.net/bugs/2103417 | 14:28 |
frickler | a) it is blocking kolla and we have no feasible workaround | 14:28 |
frickler | b) I wonder how that issue could have been detected within neutron | 14:28 |
ralonsoh | we use metadata in the L3 agent | 14:29 |
ralonsoh | I don't know if we have any test using the dhcp one | 14:29 |
frickler | well the issue in kolla isn't that metadata is broken, but that the dhcp agent is failing and thus instances don't get a dhcp response | 14:30 |
ralonsoh | the patch needs a respin, but looks fine. Could be merged today and backported | 14:30 |
frickler | I'm not sure why that doesn't happen in a devstack setup | 14:30 |
ralonsoh | we would need to check all our tempest tests | 14:31 |
haleyb | the changes to the unit test would trigger it from waht i remember from an early PS | 14:31 |
lajoskatona | the dhcp failure is not related to the eventlet change? | 14:31 |
lajoskatona | or that is a parallel one< | 14:31 |
ralonsoh | not this one | 14:31 |
lajoskatona | ack | 14:31 |
haleyb | it's from my metadata ipv6 change | 14:31 |
haleyb | i fixed one bug but caused another | 14:32 |
lajoskatona | that's life :-) | 14:32 |
ralonsoh | haleyb, will you push the new PS? | 14:32 |
lajoskatona | the dragon has endles new heads, and we had them just before release this time it seems | 14:33 |
haleyb | ralonsoh: sure i can do right after meeting if i don't see an update | 14:33 |
frickler | I'm not sure whether running a (n-v) kolla job on neutron changes would be an option, or do you think that that would be too much? | 14:33 |
ralonsoh | you can have your own neutron-master CI job | 14:34 |
ralonsoh | with a daily execution | 14:34 |
frickler | well we consume neutron from master anyway, so that would be just our normal jobs | 14:34 |
frickler | the idea would be able to recognize issues before they are merged into master | 14:35 |
ralonsoh | yes but this is expensive, just when we are removing jobs | 14:36 |
ralonsoh | when was the last time Neutron introduced an error in kolla this big? | 14:36 |
ralonsoh | also, as you said, you have your own jobs and we responded quick to this problem | 14:36 |
lajoskatona | like we have master oslo or main pyroute2 jobs to have quick alert | 14:37 |
slaweq | frickler we had in the past such kind of cross project non-voting jobs | 14:38 |
slaweq | but in order to save some infra resources we moved those jobs to periodic queue | 14:38 |
slaweq | so maybe kolla-neutron job can be in periodic line too? | 14:38 |
slaweq | and we are checking those periodic jobs weekly | 14:39 |
slaweq | so IMO it is good tradeoff | 14:39 |
lajoskatona | +1 for periodic weekly and let's check them on weekly CI meeting | 14:39 |
frickler | I think we have those already, but querying zuul is a bit slow for me right now | 14:41 |
frickler | anyway, fine for me for now | 14:41 |
haleyb | ok, we can discuss in CI meeting to see if there is any work here to help | 14:42 |
haleyb | that was all the bugs i think | 14:43 |
haleyb | this week jlibosva is the bug deputy, but i don't see him | 14:43 |
ralonsoh | I'll ping him later | 14:43 |
haleyb | can someone ping him on slack channel, thanks | 14:43 |
haleyb | next week is obondarev, is that good with you? | 14:43 |
obondarev | yep | 14:44 |
haleyb | thanks! | 14:44 |
haleyb | #topic community goals | 14:44 |
haleyb | lajoskatona: i don't see any neutronclient changes in-flight, so that's good :) | 14:45 |
haleyb | is it something to continue next cycle? | 14:45 |
haleyb | we can come back to that | 14:46 |
lajoskatona | yes, all open things merged, I have to go and find the next api topic to change to sdk | 14:46 |
haleyb | lajoskatona: ack, thanks | 14:46 |
haleyb | ralonsoh: evenlet removal is next, i'll let you give status | 14:47 |
ralonsoh | yes, in bullet points | 14:47 |
ralonsoh | SRIOV: merged | 14:47 |
ralonsoh | DHCP: reverted due to missing backend in oslo.service | 14:47 |
ralonsoh | MacVTap: I need to check, but same ^^ problem | 14:47 |
ralonsoh | L3: no activity (I had bug fixes to push) | 14:48 |
ralonsoh | OVS: https://review.opendev.org/q/topic:%22bug/2087939%22+status:open | 14:48 |
ralonsoh | that's all | 14:48 |
lajoskatona | yes we said macvtap also uses oslo.services, so have to wait with it | 14:48 |
ralonsoh | yes | 14:48 |
haleyb | ralonsoh: in your opinion, should be merge any/all of the ovs changes and get into 2025.1? i did have some comments out to sahid on one of the changes at least | 14:49 |
haleyb | #link https://review.opendev.org/c/openstack/neutron/+/940983 - i need to look again | 14:50 |
ralonsoh | no, we don't need these changes in stable | 14:50 |
haleyb | ack, that's what i thought, plus i don't want to cause breakeage | 14:50 |
ralonsoh | right | 14:51 |
haleyb | ok, anything else for community topics? | 14:51 |
opendevreview | Pierre Riteau proposed openstack/neutron master: Spawn IPv6 metadata proxy only when required https://review.opendev.org/c/openstack/neutron/+/944763 | 14:52 |
haleyb | #topic on-demand | 14:52 |
haleyb | we already discussed the OVN placement bug | 14:52 |
ralonsoh | ah yes, I added it in this list | 14:52 |
haleyb | ralonsoh: regarding the DB bug you fixed (i can't find the patch) - is that something we need to backport? | 14:53 |
ralonsoh | which one? | 14:53 |
haleyb | https://review.opendev.org/c/openstack/neutron/+/944803 | 14:53 |
haleyb | would that affect a db migration? | 14:54 |
ralonsoh | pffff to be honest, I don't know why this was not affecting the migration | 14:54 |
ralonsoh | I'll push stable only patches for the affected ones | 14:55 |
ralonsoh | that should be 2025.1 and 2024.2 | 14:55 |
ralonsoh | and 2023.1 | 14:55 |
haleyb | ack, thanks | 14:55 |
* haleyb was thinking no one uses openstack? :-p | 14:56 | |
haleyb | s/newer openstack | 14:56 |
haleyb | but then i'm not a comedian | 14:56 |
haleyb | anyways, any other topics to discuss? | 14:57 |
ralonsoh | that should be affecting the migration in the CI | 14:57 |
ralonsoh | but as I said, I have no idea why is not... | 14:57 |
haleyb | i don't either | 14:57 |
haleyb | ok, thanks for attending everyone, and ping here if there are critical things for RC2 | 14:58 |
haleyb | #endmeeting | 14:59 |
opendevmeet | Meeting ended Tue Mar 18 14:59:01 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:59 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2025/networking.2025-03-18-14.00.html | 14:59 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2025/networking.2025-03-18-14.00.txt | 14:59 |
opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2025/networking.2025-03-18-14.00.log.html | 14:59 |
lajoskatona | Bye | 14:59 |
ralonsoh | bye | 14:59 |
mlavalle | \o | 14:59 |
slaweq | o/ | 14:59 |
priteau | haleyb: Could you please review the updated dhcp metadata patch? https://review.opendev.org/c/openstack/neutron/+/944763 | 15:01 |
haleyb | priteau: lgtm, thanks! | 15:01 |
ralonsoh | haleyb, that was initially my fault: https://review.opendev.org/c/openstack/neutron/+/859111/1/neutron/db/migration/__init__.py | 15:04 |
ralonsoh | (there are other errors, mine too) | 15:05 |
ralonsoh | I'll push the fixes | 15:05 |
haleyb | oops :( | 15:06 |
opendevreview | Rodolfo Alonso proposed openstack/neutron unmaintained/2023.1: [stable-only] Fix the Neutron milestones list https://review.opendev.org/c/openstack/neutron/+/944875 | 15:08 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.2: [stable-only] Fix the Neutron milestones list https://review.opendev.org/c/openstack/neutron/+/944876 | 15:10 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2024.1: [stable-only] Fix the Neutron milestones list https://review.opendev.org/c/openstack/neutron/+/944877 | 15:13 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2024.2: [stable-only] Fix the Neutron milestones list https://review.opendev.org/c/openstack/neutron/+/944879 | 15:15 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: [stable-only] Fix the Neutron milestones list https://review.opendev.org/c/openstack/neutron/+/944880 | 15:17 |
ralonsoh | haleyb, not a single "open DB branch" without an error | 15:17 |
ralonsoh | pfffff | 15:17 |
haleyb | at least we're consistent, maybe we need to document it better | 15:17 |
ralonsoh | I has using my own previous patches | 15:18 |
ralonsoh | but of course, I started adding errors and propagate them | 15:18 |
haleyb | for example, i pushed patches yesterday to change and update jobs for 2025.2, the DB change falls in the same category. i really don't know if we document that somewhere or just rely on someone knowing what to do | 15:18 |
haleyb | "here's what to do when we start a new release" type doc | 15:19 |
haleyb | maybe it's there an i just haven't looked | 15:19 |
ralonsoh | or maybe better, some kind of UTs | 15:19 |
ralonsoh | these patches should have 1) the new milestone, 2) the identification of the latest DB migration and 3) the current release | 15:20 |
ralonsoh | I think we can handle this in a UT class, let me check that | 15:20 |
ralonsoh | at least I'll create a LP bug now | 15:21 |
opendevreview | Merged openstack/neutron master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron/+/944822 | 15:28 |
priteau | haleyb: the dhcp metadata fix has failed one check job already (not related, it's an OVN test). If I rebase it could you give it W+1 again so we don't have to wait another 1.5 hour? | 15:30 |
frickler | meh, completely unrelated ovn failure on the "kolla" fix already, is this a known issue? https://zuul.opendev.org/t/openstack/build/539ac70caed84f948edaa0382bd5623c does it make to abandon/restore the patch to get faster turnaround? or enqueue to gate directly? | 15:30 |
frickler | ah, or what priteau says ;) | 15:31 |
haleyb | ralonsoh: i added a topic to ptg as well so we don't forget | 15:31 |
opendevreview | Pierre Riteau proposed openstack/neutron master: Spawn IPv6 metadata proxy only when required https://review.opendev.org/c/openstack/neutron/+/944763 | 15:31 |
priteau | ralonsoh: haleyb: please W+1 again, thanks! | 15:31 |
haleyb | priteau: done | 15:32 |
ralonsoh | haleyb, sure thanks! | 15:44 |
ralonsoh | I've create this: https://bugs.launchpad.net/neutron/+bug/2103531 | 15:44 |
haleyb | ralonsoh: ack, thanks, just need to work on a AI-bot to do all these changes for us :) | 15:46 |
ralonsoh | haleyb, I think I know how to implement simple but effective UTs for this | 15:46 |
ralonsoh | I'll push a patch later this week (I need to focus on some bugs now) | 15:47 |
haleyb | yes, it can wait | 15:47 |
lajoskatona | haleyb, ralonsoh: this old doc should be updated also: https://docs.openstack.org/neutron/latest/contributor/policies/release-checklist.html | 15:47 |
haleyb | ralonsoh: if you have time can you look at my comment in https://review.opendev.org/c/openstack/neutron/+/943212 ? i don't know why you changed from 2 seconds there | 15:48 |
ralonsoh | lajoskatona, actually the example provided is correct... | 15:50 |
ralonsoh | haleyb, one sec | 15:50 |
haleyb | lajoskatona: oh, that's the list, we should make sure it is all up to date, for example with the CI changes we do each cycle | 15:50 |
lajoskatona | I always hated the job changes lots of possible mistakes (with my typing issues anyway....) | 15:51 |
ralonsoh | haleyb, this time in BatchNotifier is the time.sleep() used to process and notify new events | 15:52 |
ralonsoh | the shorted it, the faster we read and notify the new events | 15:52 |
ralonsoh | if no new events are added to the queue, no notification will be done | 15:52 |
ralonsoh | this is why I reduced this interval | 15:52 |
ralonsoh | the point is that we are monkey patching the self.notifier._notify method, but it could be called by other tests in parallel | 15:54 |
haleyb | ralonsoh: so i think that the 0.2 is somehow not always long enough based on the assert 2 != 3 failure - does making it longer just help the test pass? | 15:55 |
haleyb | oh, i didn't know it could be called in parallel | 15:55 |
ralonsoh | I don't think this change will improve that | 15:55 |
haleyb | it didn't, just hid it for a week | 15:55 |
ralonsoh | well, the other workers are executed in other processes | 15:56 |
ralonsoh | so that is not true... my bad | 15:56 |
ralonsoh | haleyb, why if we are adding 20 events in this test, we check call_count=2?? | 15:58 |
haleyb | ralonsoh: there is a comment below it - events are added but only triggers 2 calls in the notifier, which makes sense | 15:58 |
ralonsoh | upssss, ok, this test was relying on this 2secs interval | 15:58 |
ralonsoh | I think this is wrong... or at least prone to errors in slow envs (CI) | 15:59 |
haleyb | yes, the 2 sec comment doesn't match the code, was changed in the evenlet change | 15:59 |
haleyb | i moved to 0.2 but can put right back to 2 | 15:59 |
ralonsoh | the method ``_batch_notifier_dequeue`` should enqueue the events in a list or something | 15:59 |
ralonsoh | and then we need to check how many events have been notified | 15:59 |
ralonsoh | this is more reliable | 16:00 |
ralonsoh | in L51, we are getting the pending events | 16:00 |
ralonsoh | self.notifier._pending_events.get() | 16:00 |
ralonsoh | this is where we can add a list to store them | 16:00 |
ralonsoh | and then count them in an active wait | 16:01 |
ralonsoh | we don't need L60 check now | 16:01 |
ralonsoh | just wait_until_true(lambda: len(list_events) == 20) | 16:01 |
haleyb | ralonsoh: isn't that was the test below does kind-of? | 16:02 |
ralonsoh | I was checking that too | 16:02 |
ralonsoh | yes, that's right | 16:02 |
ralonsoh | so ``test_queue_event_multiple_events_notify_method`` makes no sense | 16:03 |
ralonsoh | we can remove it | 16:03 |
haleyb | ralonsoh: ack, since you had added that back in 2019 i figured i'd let you make the call, commit 8b7d2c8a93fdf69a828f14bd527d8f132b27bc6e | 16:05 |
ralonsoh | haleyb, that was just a refactor | 16:08 |
ralonsoh | trying to replicate what was done before | 16:08 |
ralonsoh | but this test is unnecessary | 16:08 |
haleyb | ralonsoh: i can just remove it all, easy enough | 16:08 |
ralonsoh | perfect | 16:08 |
ralonsoh | I need to leave now, I'll connect again in some hours | 16:09 |
ralonsoh | haleyb, https://review.opendev.org/q/Ie391af5a3b226cbd33f7162a3c970d636fcdf1da | 16:12 |
ralonsoh | if you have 1 min | 16:12 |
opendevreview | Dong Ma proposed openstack/ovn-bgp-agent master: Add the support of create kubernetes resource https://review.opendev.org/c/openstack/ovn-bgp-agent/+/937457 | 16:46 |
haleyb | zigo: rodolfo had opened https://bugs.launchpad.net/neutron/+bug/2103514 for the mtu issue you saw, can you check that and provide any more info? thanks | 17:14 |
*** dmellado0755393733 is now known as dmellado075539373 | 17:14 | |
zigo | haleyb: will do tomorow, got all in a private gitlab issue. | 17:16 |
opendevreview | Maor Blaustein proposed x/whitebox-neutron-tempest-plugin master: [DNM] Test metadata rate limiting - master devstack ovn https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/944921 | 18:00 |
opendevreview | Candido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: Increase burst window size to avoid unstabilities in slow envs https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/944616 | 18:29 |
opendevreview | Merged openstack/neutron stable/2024.1: [OVN] Do not delete twice the agent from the cache https://review.opendev.org/c/openstack/neutron/+/944394 | 18:36 |
opendevreview | Merged openstack/neutron stable/2023.2: [OVN] Do not delete twice the agent from the cache https://review.opendev.org/c/openstack/neutron/+/944396 | 18:36 |
opendevreview | Merged openstack/neutron master: Spawn IPv6 metadata proxy only when required https://review.opendev.org/c/openstack/neutron/+/944763 | 19:58 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: Spawn IPv6 metadata proxy only when required https://review.opendev.org/c/openstack/neutron/+/944943 | 20:05 |
opendevreview | Jakub Libosvar proposed openstack/ovn-bgp-agent master: Use OS_TEST_PATH evironment variable to define tests location https://review.opendev.org/c/openstack/ovn-bgp-agent/+/944945 | 20:26 |
opendevreview | Brian Haley proposed openstack/neutron master: Remove flaky batch notifier unit test https://review.opendev.org/c/openstack/neutron/+/944950 | 21:08 |
ralonsoh | haleyb, what is SUT? | 21:08 |
haleyb | ralonsoh: system under test, i couldn't think of anything better | 21:17 |
haleyb | i can change it | 21:17 |
ralonsoh | no no, just asking | 21:44 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Make the Logical_Switch_Port UP event more robust https://review.opendev.org/c/openstack/neutron/+/943404 | 21:45 |
opendevreview | Brian Haley proposed openstack/neutron stable/2024.2: Optionally configure IPv6 metadata address https://review.opendev.org/c/openstack/neutron/+/944496 | 22:01 |
opendevreview | Merged openstack/neutron master: Revert "[eventlet-removal] Remove the usage of eventlet in the DHCP agent" https://review.opendev.org/c/openstack/neutron/+/944634 | 23:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!