| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Bump advance image to Ubuntu Jammy Server 22.04 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/949140 | 01:06 |
|---|---|---|
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Add test job for address_group api backend Ml2/OVN https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/906020 | 01:13 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Add test job for address_group api backend Ml2/OVN https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/906020 | 01:16 |
| opendevreview | Merged openstack/neutron stable/2025.1: [OVN] Create a HA_Chassis_Group without raising an exception https://review.opendev.org/c/openstack/neutron/+/949699 | 03:53 |
| opendevreview | Merged openstack/neutron master: [OVN] Do not supply gateway_port if it's not bound to chassis https://review.opendev.org/c/openstack/neutron/+/931495 | 03:54 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: List networks with limit and filter by provider network attrs https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/949975 | 06:45 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Bump advance image to Ubuntu Jammy 22.04 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/949140 | 07:45 |
| opendevreview | Merged x/whitebox-neutron-tempest-plugin master: test_attach_qos_port_to_vm_with_another_port: Create VMs on different hosts https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/950296 | 08:06 |
| ralonsoh | lajoskatona, hello! I | 08:07 |
| ralonsoh | (sorry) | 08:07 |
| ralonsoh | I' | 08:07 |
| ralonsoh | ahhhh | 08:07 |
| ralonsoh | I'm going to test the DHCP agent with the oslo.service patch | 08:07 |
| ralonsoh | Most probably, checking the code, we'll need something like this | 08:08 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/949135 | 08:08 |
| ralonsoh | I don't know if you are working on this right now | 08:08 |
| lajoskatona | ralonsoh: Hi, this week I had no time for it, I have only a PoC in my local env | 08:23 |
| ralonsoh | lajoskatona, ok so I can wait then if you already have something | 08:23 |
| ralonsoh | folks, please check https://review.opendev.org/q/topic:%22bug/2109354%22 if you have time | 08:26 |
| lajoskatona | ralonsoh: ack, thanks | 08:30 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] OVN agent retrieval filter matching improvement https://review.opendev.org/c/openstack/neutron/+/949584 | 08:30 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Delete the metadata agent file from the eventlet directory https://review.opendev.org/c/openstack/neutron/+/950384 | 08:33 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: Delete the metadata agent file from the eventlet directory https://review.opendev.org/c/openstack/neutron/+/950385 | 08:33 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Require alembic db migration scripts to be idempotent https://review.opendev.org/c/openstack/neutron/+/950139 | 09:17 |
| gibi | ralonsoh: lajoskatona: I see eventlet related errors in the neutron API logs in the nova CI. Could this be related to recent eventlet work? | 11:58 |
| gibi | https://zuul.opendev.org/t/openstack/build/9723dbce3c0f4311881d8095d5dc347c/log/controller/logs/screen-q-svc.txt?severity=4#4499 | 11:58 |
| gibi | May 19 13:52:48.420978 np0040808677 neutron-server[76758]: ERROR ovsdbapp.event RuntimeError: Second simultaneous write on fileno 9 detected. Unless you really know what you're doing, make sure that only one greenthread can write any particular socket. Consider using a pools.Pool. If you do know what you're doing and want to disable this error, call | 11:58 |
| gibi | eventlet.debug.hub_prevent_multiple_readers(False) - MY THREAD=<built-in method switch of greenlet.greenlet object at 0x732238af5240>; THAT THREAD=FdListener('write', 9, <built-in method switch of greenlet.greenlet object at 0x732239a11580>, <built-in method throw of greenlet.greenlet object at 0x732239a11580>) | 11:59 |
| lajoskatona | gibi: anything can happen :-) | 12:07 |
| ralonsoh | gibi, let me check | 12:29 |
| gibi | thanks | 12:30 |
| ralonsoh | gibi, why is Nova still using the eventlet server?? | 12:32 |
| ralonsoh | let me check the devstack config | 12:32 |
| ralonsoh | gibi, https://review.opendev.org/c/openstack/devstack/+/932199 | 12:40 |
| ralonsoh | I was looking for something related | 12:40 |
| ralonsoh | since 7 hours ago, the default Neutron server will be WSGI, not the eventlet that is on these logs | 12:40 |
| ralonsoh | so we don't need to change any job definition | 12:41 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [FT] Check the SB Port_Binding is created before test execution https://review.opendev.org/c/openstack/neutron/+/950408 | 12:48 |
| haleyb | #startmeeting networking | 13:00 |
| opendevmeet | Meeting started Tue May 20 13:00:35 2025 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:00 |
| opendevmeet | The meeting name has been set to 'networking' | 13:00 |
| haleyb | Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh | 13:00 |
| mlavalle | \o | 13:00 |
| mtomaska | o/ | 13:00 |
| ralonsoh | hello | 13:00 |
| ykarel | o/ | 13:00 |
| rubasov | o/ | 13:00 |
| obondarev | o/ | 13:00 |
| haleyb | alright we can get started | 13:01 |
| lajoskatona | o/ | 13:01 |
| haleyb | #announcements | 13:01 |
| haleyb | We are currently in Week R-18 of Flamingo | 13:01 |
| haleyb | we just completed Flamingo-1 | 13:02 |
| haleyb | Our next milestone in this development cycle will be Flamingo-2, on July 3rd | 13:02 |
| haleyb | This milestone is when we freeze the list of deliverables that will be included in the 2025.2 Flamingo final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/flamingo directory of the openstack/releases repository | 13:02 |
| haleyb | Final 2025.2 Flamingo release: October 3rd, 2025 | 13:03 |
| haleyb | #link https://releases.openstack.org/flamingo/schedule.html | 13:03 |
| haleyb | Reminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers | 13:03 |
| haleyb | the meeting last week was canceled, i will look at new rfes for this week | 13:04 |
| bcafarel | late o/ | 13:04 |
| haleyb | as i was out last week and only worked a few hours, any fires i should be aware of? i didn't see anything on the ML or irc backtrace | 13:04 |
| ralonsoh | nothing urgent/critical | 13:05 |
| haleyb | ack, thanks for taking care of the place :) | 13:05 |
| haleyb | i had no other announcements, anyone else have something? | 13:06 |
| haleyb | #topic bugs | 13:06 |
| haleyb | bcafarel was the deputy last week, his report is at | 13:06 |
| haleyb | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/GCVMPXGHVV535VPUNYP2LUDM6PKBKV5W/ | 13:06 |
| haleyb | not too many bugs | 13:06 |
| bcafarel | I got lucky it seems :) | 13:07 |
| haleyb | and it looks like most got an owner and a patch | 13:07 |
| haleyb | there was only one CI-related one | 13:08 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2110878 | 13:08 |
| haleyb | only seen once | 13:08 |
| ralonsoh | I'll check it today | 13:09 |
| haleyb | ack, thanks | 13:09 |
| haleyb | any other bugs to discuss? | 13:09 |
| mtomaska | I forgot to include one bug in my last week report. https://bugs.launchpad.net/neutron/+bug/2110085 | 13:09 |
| haleyb | that might be a duplicate? | 13:10 |
| haleyb | ralonsoh: that one looks like something you've been working on? | 13:10 |
| trident | Any chance there could be some eyes on https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1924776 - If I have not misunderstood something, this kind of limits the use of address scopes with OVN pretty severely as it doesn't honor address scopes when taking the decision of using NAT or not between two networks connected to a router as I think it should. | 13:10 |
| mtomaska | Duplicate? I have to look, but I feel like this is known issue | 13:10 |
| ralonsoh | mtomaska, are there any logs? | 13:10 |
| mtomaska | no | 13:11 |
| slaweq | o/ sorry for being late | 13:11 |
| mtomaska | except what is in the bug already | 13:11 |
| ralonsoh | ok, let me check that out of this meeting | 13:12 |
| ralonsoh | I'll assign this one to me | 13:12 |
| haleyb | trident: that seems like an old bug, does this still happen on master branch? | 13:12 |
| mtomaska | I feel like this was discussed somewhere that uwsgi is only single threaded.... or I might be confusing with something else. | 13:13 |
| haleyb | trident: we can discuss after meeting | 13:13 |
| lajoskatona | isn't that related to what gibi posted few hours back ? (https://meetings.opendev.org/irclogs/%23openstack-neutron/%23openstack-neutron.2025-05-20.log.html#openstack-neutron.2025-05-20.log.html#t2025-05-20T11:58:47) | 13:13 |
| lajoskatona | I mean the wsgi thing? | 13:14 |
| ralonsoh | lajoskatona, no, this one is using eventlet server | 13:14 |
| lajoskatona | oh no that is something eventlet | 13:14 |
| lajoskatona | ralonsoh: yeah, ack | 13:14 |
| ralonsoh | the bug reported is using wsgi | 13:14 |
| trident | haleyb: Ok, thanks! | 13:14 |
| ralonsoh | trident, haleyb I tried last week to make this feature work | 13:14 |
| ralonsoh | without any success | 13:14 |
| ralonsoh | so I think this is not supported in ml2/ovn (I'm not saying in OVN, just could be a bad implementation in Neutron) | 13:15 |
| ralonsoh | So I think the bug is legit | 13:15 |
| haleyb | yes, i remember you doing some address scope testing | 13:15 |
| ralonsoh | related to another feature, yes | 13:15 |
| ralonsoh | let's talk after the meeting | 13:15 |
| haleyb | ack | 13:16 |
| opendevreview | Lajos Katona proposed openstack/os-vif master: VS Trunk: Add bridge_name to external_ids https://review.opendev.org/c/openstack/os-vif/+/949736 | 13:16 |
| haleyb | this week the deputy is elvira, next week is slaweq - does that work for both of you? | 13:16 |
| haleyb | ok, i will ping people again later | 13:18 |
| haleyb | #topic community goals | 13:18 |
| haleyb | lajoskatona: any update on neutronclient changes? | 13:18 |
| slaweq | yeap | 13:18 |
| lajoskatona | yes, | 13:18 |
| lajoskatona | yesterday I found (thanks for reviewers in horizon) that in SDK there is no shared field for sec-groups: https://review.opendev.org/c/openstack/openstacksdk/+/950305 | 13:19 |
| elvira | (yes, it works, sorry for the late answer o/) | 13:19 |
| lajoskatona | and pushed also a patch for QoS: https://review.opendev.org/c/openstack/horizon/+/949764 | 13:20 |
| haleyb | elvira, slaweq - thanks | 13:20 |
| lajoskatona | but no time for fullstack vs SDK patch (the no-auth problem) :https://review.opendev.org/c/openstack/neutron/+/947851 | 13:21 |
| haleyb | lajoskatona: thanks! i've started watching both | 13:21 |
| lajoskatona | that's it for neutronclient | 13:21 |
| haleyb | great, thanks for the update | 13:21 |
| lajoskatona | some CI is failing I have to go back to see what I broke | 13:21 |
| haleyb | ack | 13:21 |
| haleyb | ralonsoh: and finally eventlet | 13:22 |
| ralonsoh | nothing new in gerrit | 13:22 |
| ralonsoh | I've started with the migration of the tests, but locally | 13:22 |
| ralonsoh | please check https://review.opendev.org/c/openstack/neutron/+/949135 | 13:22 |
| ralonsoh | something similar will be needed for the DHCP agent | 13:23 |
| ralonsoh | that's all | 13:23 |
| haleyb | ack, thanks, will look | 13:23 |
| lajoskatona | I work on the dhcp agent | 13:23 |
| ralonsoh | lajoskatona, thanks! | 13:24 |
| haleyb | ralonsoh: there was one change that Liu was having an issue with, do we need to discuss that further? i'd have to find the link | 13:24 |
| ralonsoh | one sec | 13:24 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/948200 | 13:24 |
| ralonsoh | now with functional tests | 13:24 |
| ralonsoh | we can talk about this one in the on-demand section | 13:25 |
| ralonsoh | actually, I would like to bring it back | 13:25 |
| lajoskatona | but for that topic there are patches from Liu also: https://review.opendev.org/q/topic:%22bug/2106463%22 | 13:25 |
| haleyb | ralonsoh: i can start on-demand | 13:26 |
| haleyb | #topic on-demand | 13:26 |
| ralonsoh | lajoskatona, yes, I also mentioned that the DB constraint introduced is against what we consider a tunnelled network | 13:27 |
| opendevreview | Merged openstack/neutron-lib master: api-ref: Add warning about DRA scheduler https://review.opendev.org/c/openstack/neutron-lib/+/949744 | 13:27 |
| ralonsoh | for any tunnelled network, the physical network is None, not an empty string | 13:27 |
| ralonsoh | and as I commented, my patch is backportable, fixes the problem with multiple workers (this is now executed in the first one only) | 13:27 |
| ralonsoh | and works for multiple servers booting at the same time | 13:28 |
| haleyb | ralonsoh: is there any merit to also doing the DB constraint going forward? although it's not necessary with all your code | 13:29 |
| ralonsoh | it is not necessary this db constraint | 13:29 |
| ralonsoh | I also remember trying to introduce something similar years ago | 13:29 |
| haleyb | ack | 13:30 |
| ralonsoh | in any case, if we want the constraint added, it could be on top of my patch | 13:30 |
| haleyb | yes, not instead of, on-top for now and future | 13:31 |
| ralonsoh | no problem **IF** we don't add an empty string for tunnelled networks in the physical network | 13:31 |
| haleyb | we need to backport | 13:31 |
| ralonsoh | yes, my patch is enough and backportable | 13:31 |
| haleyb | so i guess we can wait for his response, i also do not understand | 13:32 |
| opendevreview | Merged openstack/neutron-lib master: api-ref: Remove crud from conf.py https://review.opendev.org/c/openstack/neutron-lib/+/949745 | 13:32 |
| ralonsoh | I have another quick topic | 13:33 |
| ralonsoh | #link https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/949140 | 13:33 |
| ralonsoh | I addressed yatin's comment: I'm using ubuntu server only in OVN, due to the issues with IGMP | 13:34 |
| ralonsoh | about lajoskatona's comment: the issue is that using Focal VM is a problem in the CI | 13:34 |
| lajoskatona | ralonsoh: ack, checking | 13:34 |
| ralonsoh | I understand the logic of this comment: do not change what is working | 13:34 |
| haleyb | ralonsoh: yes, we should move to jammy or jammy server | 13:35 |
| ralonsoh | but the problem is that we are hitting some errors in the CI with focal image | 13:35 |
| ralonsoh | haleyb, I've used both | 13:35 |
| ralonsoh | minimal by default, server only in ovn (for IGMP) | 13:35 |
| haleyb | ah, ok, one is the minimal now | 13:35 |
| ralonsoh | with a note to go back to minimal if there is a fix | 13:35 |
| ralonsoh | and that's all, thanks! | 13:36 |
| haleyb | ack, thanks, i did start watching that bug too | 13:36 |
| haleyb | so last on-demand topic is mine | 13:37 |
| haleyb | i created backports for a patch that landed in 2025.1 | 13:37 |
| haleyb | #link https://review.opendev.org/c/openstack/neutron/+/851509 | 13:37 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/1982287 | 13:38 |
| haleyb | the bug was added as an rfe | 13:38 |
| haleyb | since the dependend ovsdbapp code landed in 2024.1 i wanted to backport this neutron fix to there as well | 13:38 |
| haleyb | i do understand ralonsoh's point last week that this was a feature, but i feel it was something missed | 13:39 |
| ralonsoh | if we accept these backports, I would change the reno from "feature" to "other" in the stable branches | 13:40 |
| haleyb | ralonsoh: i am relating this change to the one we did for ovs hybrid driver | 13:40 |
| haleyb | #link https://review.opendev.org/c/openstack/neutron/+/913708 | 13:40 |
| haleyb | that one we backported from 2024.1 to yoga | 13:41 |
| haleyb | so i wanted to get other opinions on the OVN one | 13:41 |
| haleyb | i did find a tempest patch that never merged to test it all, which i have updated | 13:41 |
| haleyb | #link https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/906020 | 13:41 |
| ralonsoh | I'm ok, but let's change the reno to avoid the wrath of release team. I would add something like "testing feature" | 13:42 |
| haleyb | that seems to have failed miserably overnight | 13:42 |
| haleyb | ralonsoh: ack, i can update the release note on the backports | 13:43 |
| lajoskatona | The RFE label is really a headsup thing but as I understand this patch fixed the OVN backend | 13:43 |
| haleyb | i am worried about why the n-t-p change took a turn, but will have to look at logs | 13:43 |
| lajoskatona | +1 | 13:43 |
| ralonsoh | yeah, lets make the n-t-p patch work with the dependencies to the backports | 13:44 |
| haleyb | once the backports merge i will update n-t-p to test on those branches | 13:44 |
| haleyb | ralonsoh: sure, i could do that as well | 13:44 |
| ralonsoh | just to test before merge | 13:44 |
| haleyb | i will do that right after meeting, is related to something hot downstream | 13:45 |
| haleyb | thanks for the discussion everyone | 13:45 |
| haleyb | that was all the topics, anything else to discuss? | 13:46 |
| haleyb | ok, thanks for attending everyone, have a great week | 13:46 |
| haleyb | #endmeeting | 13:46 |
| opendevmeet | Meeting ended Tue May 20 13:46:33 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:46 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2025/networking.2025-05-20-13.00.html | 13:46 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2025/networking.2025-05-20-13.00.txt | 13:46 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2025/networking.2025-05-20-13.00.log.html | 13:46 |
| mlavalle | \o | 13:46 |
| lajoskatona | o/ | 13:46 |
| bcafarel | o/ | 13:46 |
| ralonsoh | bye | 13:46 |
| * bcafarel adds backport to the review list (if it's "optimisation" using direct OVN existing for address sets, can be good to hvae) | 13:47 | |
| ralonsoh | +1 | 13:47 |
| trident | ralonsoh, haleyb: I have not recently tested with master, but seems like you have confirmed https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1924776 is still around ralonsoh? | 13:48 |
| haleyb | bcafarel: remote address groups in SGs doesn't work in OVN without that fix, i've tried :( | 13:48 |
| ralonsoh | trident, yes, that doesn't work for me in master | 13:48 |
| haleyb | bcafarel: well, on caracal that is, it works on 2025.1 | 13:48 |
| haleyb | caracal is this important LTS release people like :) | 13:49 |
| trident | I am pretty much trying to replicate the behaviour with ml2/ovs, the most common use case here is for IPv6, where the "link" network on ext-net and tenant networks created from IPv6 pool is doesn't use NAT as well as being BGP announced. While a tenant network with a random IPv6 prefix won't get announced. But we use it here and there for IPv4 as well. | 13:51 |
| bcafarel | haleyb: ack, so it sounds useful to have backported if possible :) | 13:51 |
| haleyb | bcafarel: yes, i'd put it on the OVN/ML2-OVS gap category | 13:52 |
| trident | It can be somewhat worked around by manually setting the snat flag, but if a router has one subnet connected that should do NAT and one that shouldn't I guess that won't work. Also the BGP announcement filtering can be somewhat worked around as well by manually specifying the address scopes that should be announced, but that is not so dynamic. | 13:52 |
| haleyb | trident: IPv6 shouldn't use NAT either way we don't support it in neutron | 13:53 |
| trident | haleyb: Hm, true. Then for IPv6 it's only the issue of only BGP announce tenant subnet prefix:es created from a subnet pool in the same address scope as ext-net:s IPv6 subnet. | 13:56 |
| trident | haleyb: But for IPv4 both the issues are present. | 13:58 |
| haleyb | trident: ack, can you add that info to the bug? and any other steps you've used to recreate if not already there | 13:58 |
| trident | And there should probably be another bug for using address scopes to dynamically announce or not announce prefixes like dragent does. Will look into filing such a bug as well. | 13:59 |
| trident | As they are really separate issues. | 14:00 |
| trident | haleyb: Yes. I'll look into what more information I can provide in the bug. (I was not the initial reporter). | 14:00 |
| haleyb | +1 | 14:04 |
| dansmith | I'm trying to get a local multinode devstack install running and I need actual networking to do my test, but I'm struggling with neutron | 14:11 |
| dansmith | the issue I'm hitting looks like this unfixed bug: https://bugs.launchpad.net/neutron/+bug/1816502 | 14:11 |
| dansmith | here's my actual failure: https://paste.opendev.org/show/bzjEWeg3yo6nPQ1qNHpQ/ | 14:11 |
| dansmith | that seems really odd because I would not expect a 500 and a huge stack trace in the server logs from something a user does if it's just mis-specifying a prefix or something | 14:12 |
| dansmith | can someone help? | 14:12 |
| dansmith | localrc content relevant to neutron is: https://paste.opendev.org/show/buLgNKNZsgTW2U2vxyZQ/ | 14:13 |
| gibi | ralonsoh: OK, so something does changing and we expect that after the wsgi change in devstack this will not happen again. Thanks. I will report back if I see this again in the future | 14:17 |
| ralonsoh | gibi, for sure and thanks for checking | 14:17 |
| ralonsoh | dansmith, let me check | 14:17 |
| ralonsoh | dansmith, do you have the Neutron API logs? | 14:20 |
| dansmith | ralonsoh: yeah, how much do you want to see? there's a massive traceback in there | 14:21 |
| ralonsoh | just during the subnet creation | 14:22 |
| ralonsoh | what version are you using? | 14:22 |
| dansmith | here's a big chunk: https://paste.opendev.org/show/b2FyWVYNnOPAdjjsnDoP/ | 14:22 |
| dansmith | version? of neutron? 993ada3ecc Remove installation guide for openSUSE/SLES | 14:23 |
| ralonsoh | so almost the last one (if not the last) | 14:23 |
| dansmith | right | 14:24 |
| dansmith | it's devstack, so master | 14:24 |
| ralonsoh | dansmith, the network GW 192.168.122.135 is not in the range of 192.168.122.0/26 | 14:30 |
| dansmith | ralonsoh: okay tbh, I don't understand what I'm supposed to be giving it.. I thought 122.0/16 is the chunk of the existing network that neutron can hand out on its own | 14:31 |
| ralonsoh | dansmith, not 122.0/16, you wrote 122.0/26 | 14:31 |
| dansmith | i.e. FIXED_RANGE= needs to be unallocated to other stuff right? | 14:31 |
| dansmith | ralonsoh: right, sorry, typo | 14:31 |
| ralonsoh | dansmith, this is a private network, it won't be connected to a host network | 14:32 |
| ralonsoh | even if the IPs are the same | 14:32 |
| dansmith | okay I'm super confused about all the things in the localrc then.. seems like there's not a lot of good documentation about what those need to be so I pieced together from a CI job | 14:32 |
| dansmith | IPs in FIXED_RANGE= are not going to be used for anything? | 14:32 |
| ralonsoh | dansmith, you have the PUBLIC_NETWORK_GATEWAY, that could be an IP of you host, if you can route the traffic from there | 14:33 |
| dansmith | ralonsoh: I have two boxes on the same L2, one devstack master, one devstack compute node.. I just need to be able to spin up instances on either and be able to ssh into them.. that L2 is 192.168.122.0/24 | 14:34 |
| dansmith | can you just explain what I need to set the localrc things to? | 14:34 |
| ralonsoh | fixed range is of the private network, it could be anything | 14:34 |
| ralonsoh | dansmith, you need to have connectivity for the services, using this 192.168.122.0 network. And then you need to create the underlaying network for the user traffic | 14:36 |
| ralonsoh | It would be better if you check a multinode deployment in zuul | 14:37 |
| ralonsoh | let me check | 14:37 |
| dansmith | ralonsoh: based on what I said above, is this right? https://paste.opendev.org/show/btoV4MPyLET5tzWzjfva/ | 14:37 |
| dansmith | ralonsoh: I've looked at them in zuul conf, but it's hard to know which networks are which just from that.. that's what I startedf rom | 14:37 |
| ralonsoh | dansmith, the NETWORK_GATEWAY variable is the private network GW IP. This is not the same as PUBLIC_NETWORK_GATEWAY | 14:38 |
| ralonsoh | the NETWORK_GATEWAY will be used for the tenant networks | 14:38 |
| dansmith | so does that need to be an IP on the 172.16.0.0 network? | 14:38 |
| ralonsoh | that could be anything | 14:38 |
| ralonsoh | yes | 14:38 |
| dansmith | ack | 14:38 |
| ralonsoh | also be aware of the floating IP range | 14:39 |
| ralonsoh | 0./26 does not contain 122.135 | 14:39 |
| ralonsoh | https://www.calculator.net/ip-subnet-calculator.html?cclass=any&csubnet=26&cip=192.168.122.0&ctype=ipv4&x=Calculate | 14:39 |
| dansmith | yeah, I know it doesn't.. how can it? | 14:39 |
| opendevreview | Ivan Anfimov proposed openstack/neutron master: Remove code for suse from post-devstack installation https://review.opendev.org/c/openstack/neutron/+/950364 | 14:39 |
| dansmith | if it does, won't neutron try to re-assign that IP, or the IP of other things there? I was trying to give it a routable segment that won't have other things assigned | 14:40 |
| dansmith | both devstack boxes will have an IP there | 14:40 |
| ralonsoh | no, the public network GW IP is an external IP | 14:40 |
| ralonsoh | that won't be in Neutron, ever | 14:40 |
| ralonsoh | Neutron won't create a port with this IP in the external network | 14:41 |
| dansmith | okay so 192.168.122.0/24 and it will exclude 135 because PUBLIC_NETWORK_GATEWAY ? | 14:41 |
| ralonsoh | yes | 14:41 |
| dansmith | how does neutron know to exclude the compute node, which might be .136 ? or the dhcp server which might be .200 ? | 14:41 |
| ralonsoh | once created the env, try to create a port with this IP | 14:41 |
| ralonsoh | this is an external network | 14:42 |
| ralonsoh | you need always to be careful with it | 14:42 |
| ralonsoh | you can have this (one sec) | 14:42 |
| ralonsoh | dansmith, | 14:43 |
| ralonsoh | https://paste.opendev.org/show/b12vKW9b2cAZzeeLZPsF/ | 14:43 |
| ralonsoh | allocation pools | 14:43 |
| dansmith | ah, is that what IPV4_ADDRS_SAFE_TO_USE sets? | 14:44 |
| ralonsoh | that means: Neutron will assign an IP address on this pool, that could be a reduced set of the subnet range | 14:44 |
| ralonsoh | let me check devstack | 14:44 |
| ralonsoh | SUBNETPOOL_PREFIX_V4=${SUBNETPOOL_PREFIX_V4:-$IPV4_ADDRS_SAFE_TO_USE} | 14:44 |
| ralonsoh | exactly | 14:44 |
| dansmith | okay so: https://paste.opendev.org/show/bgF6zrB26MnOBpYbFZP9/ | 14:44 |
| dansmith | floating covers the whole subnet, but SAFE_TO_USE is only the first chink | 14:45 |
| dansmith | *chunk | 14:45 |
| ralonsoh | yes | 14:45 |
| dansmith | okay I'll give that a shot, thanks for your help, sorry for the dumb questions | 14:45 |
| dansmith | however, seems like this should not generate a 500 and stack trace, no? | 14:46 |
| ralonsoh | not this config, I think | 14:47 |
| ykarel | ralonsoh, dansmith i recall seeeing this error | 14:48 |
| ykarel | iirc restart fixes this, so something during initialization missed | 14:48 |
| dansmith | my point is, it should be "400: User did omething wrong" not "500: server crashed" | 14:49 |
| ykarel | restart neutron api | 14:49 |
| ralonsoh | dansmith, in this particular config, the problem was that the GW IP was not in the range of the subnet | 14:49 |
| ralonsoh | ykarel, ^ | 14:49 |
| ykarel | it's not user thing, but initialzation issue on server | 14:49 |
| dansmith | ralonsoh: no, I understand, but that's a client error (4xx) not a server error (5xx) | 14:49 |
| ralonsoh | yes... that's a weird error | 14:50 |
| dansmith | I am the user here, I screwed up, so it should be 4xx | 14:50 |
| ralonsoh | "let me try this at home" | 14:50 |
| dansmith | I came here because 5xx tells me "neutron screwed up" :P | 14:50 |
| ykarel | okk after re reading the error, i see it's not the same issue that i recalled | 14:51 |
| ykarel | so ignore me | 14:51 |
| slaweq | ralonsoh dansmith I always have this explanation in my head when it is about HTTP codes: https://www.reddit.com/r/ProgrammerHumor/comments/2rttnv/http_status_ranges_in_a_nutshell/ :) | 14:52 |
| ralonsoh | hehehe correct! | 14:52 |
| dansmith | slaweq: exactly :) | 14:52 |
| dansmith | "5xx: file a bug and ping ralonsoh on IRC to fix" ... "4xx: ping ralonsoh on IRC to see what you did wrong" :) | 14:53 |
| ykarel | we have some multinode devstack config https://github.com/openstack/neutron/tree/master/devstack for both ovs/ovn | 14:53 |
| ykarel | not sure how up to date these are though | 14:53 |
| slaweq | we should fix it | 14:55 |
| slaweq | and I agree that in any case it shouldn't be 500 what's returned to user | 14:55 |
| slaweq | IM | 14:55 |
| slaweq | IMO | 14:55 |
| ralonsoh | dansmith, confirmed: if you use a subnet pool and you try to assign a GW IP that cannot be retrieved from the subnet pool (because is out of range or this range is already used) | 14:57 |
| ralonsoh | that will return a HTTP 500 SubnetAllocationError | 14:57 |
| dansmith | ack | 14:57 |
| dansmith | consistency is good at least :) | 14:57 |
| lajoskatona | ralonsoh: for eventlet + oslo.service: I think I can push tomorrow wip patches (like I saw it working) | 15:03 |
| ralonsoh | lajoskatona, cool! | 15:03 |
| ralonsoh | could you first push the RPC change independently? | 15:03 |
| ralonsoh | that should work with and withoyt eventlet | 15:03 |
| lajoskatona | ralonsoh: but, I have to add oslo.service.backend.init_backend(backend.BackendType.THREADING) somewhere here: https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/dhcp_agent.py#L22 | 15:03 |
| lajoskatona | otherwise I have eventlet | 15:04 |
| ralonsoh | lajoskatona, not there, in the agent | 15:04 |
| ralonsoh | one sec | 15:04 |
| lajoskatona | yes that's good idea to have that in separate change | 15:04 |
| ralonsoh | lajoskatona, https://review.opendev.org/c/openstack/neutron/+/938404/17/neutron/cmd/agents/l3.py | 15:04 |
| ralonsoh | (in the dhcp one, of course) | 15:04 |
| ralonsoh | this is the first code executed | 15:05 |
| lajoskatona | ralonsoh: ohh, I see, I move it there than | 15:07 |
| dansmith | oye, ralonsoh same issue when I restack.. the /26 got used on the subnet again for the prefix, so there must be more devstacky stuff going on | 15:07 |
| ralonsoh | dansmith, please, send me the devstack and neutorn logs | 15:07 |
| ralonsoh | I need to go now, but I'll check them later | 15:08 |
| ralonsoh | you can send it in private | 15:08 |
| *** ralonsoh is now known as ralonsoh_out | 15:08 | |
| dansmith | SUBNETPOOL_PREFIX_V4=${SUBNETPOOL_PREFIX_V4:-$IPV4_ADDRS_SAFE_TO_USE} | 15:09 |
| dansmith | it uses the safe-to-use for the prefix as well, not FLOATING_RANGE apparently | 15:09 |
| opendevreview | Merged openstack/neutron stable/2025.1: [OVN] Only update the MTU of the router GW LRPs https://review.opendev.org/c/openstack/neutron/+/949136 | 15:22 |
| opendevreview | Merged openstack/neutron stable/2024.1: AddressGroup API collection should be the resource name in plural https://review.opendev.org/c/openstack/neutron/+/949972 | 16:03 |
| *** jcosmao is now known as Guest16423 | 19:26 | |
| opendevreview | Brian Haley proposed openstack/neutron stable/2024.2: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/949852 | 19:37 |
| opendevreview | Brian Haley proposed openstack/neutron stable/2024.1: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/949854 | 19:38 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Add test job for address_group api backend Ml2/OVN https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/906020 | 19:43 |
| haleyb_ | mlavalle: not sure if you're around, but can you take a look at https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/949140 ? | 21:00 |
| haleyb_ | gate seems worse since this morning | 21:00 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!