| rm_work[m] | Is there ongoing effort somewhere to clean up some of the unreliable tests that keep hitting folks in CI? I am down to help spend some cycles analyzing and trying to propose improvements, but don't want to duplicate effort if patches exist | 01:48 |
|---|---|---|
| rm_work[m] | I'm seeing one in neutron-functional with test_create_router_port | 01:51 |
| opendevreview | Adam Harwell proposed openstack/neutron master: Fix race in test_create_router_port functional test https://review.opendev.org/c/openstack/neutron/+/996729 | 02:06 |
| rm_work[m] | did a quick (AI) attempt at fixing, reviewing it myself now | 02:07 |
| opendevreview | Adam Harwell proposed openstack/neutron master: Fix race in test_create_router_port functional test https://review.opendev.org/c/openstack/neutron/+/996729 | 02:09 |
| opendevreview | Adam Harwell proposed openstack/neutron master: Fix race in test_create_router_port functional test https://review.opendev.org/c/openstack/neutron/+/996729 | 02:10 |
| rm_work[m] | (sorry for the noise -- didn't like how it was doing it and sometimes it is hasty on pushing_ | 02:11 |
| rm_work[m] | s/pushing_/pushing)/ | 02:11 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Check zuul jobs migration vxlan only required jobs https://review.opendev.org/c/openstack/neutron/+/996388 | 05:04 |
| opendevreview | Merged openstack/neutron master: ovn: Filter provider networks at DB level in ``check_fdb_aging_settings`` https://review.opendev.org/c/openstack/neutron/+/995967 | 05:32 |
| frickler | rm_work[m]: ykarel_ and others are doing regular reviews of CI stability and there is even a weekly meeting dedicated to CI topics | 06:01 |
| rm_work[m] | ok cool, I wonder if that one was tackled | 06:02 |
| rm_work[m] | ralonsoh: so https://review.opendev.org/c/openstack/neutron/+/995162 is on the end of your chain -- that is literally ALL that is required for ASGI to be functional (proven by the full tempest run there, AFAICT) | 06:08 |
| rm_work[m] | I did notice you removed your -2... do you still think those 3 lines of code need an RFC? | 06:09 |
| rm_work[m] | I can do it, but it seems... a lot for adding 3 lines of an optional fallback | 06:09 |
| frickler | you can check https://meetings.opendev.org/#Neutron_CI_team , likely the meeting time isn't ideal for you, though | 06:11 |
| *** ykarel_ is now known as ykarel | 06:15 | |
| ralonsoh | rm_work[m], today I'm presenting the RFE 2158981, that supports the three patches before yours | 06:17 |
| rm_work[m] | ok, I mean your work gets us 90% of the way there, I just need those other three lines :D | 06:18 |
| ralonsoh | this RFE is not only for ASGI, is to support anything but uWSGI | 06:18 |
| rm_work[m] | ah ok | 06:18 |
| rm_work[m] | so it WOULD cover my change as well, theoretically? | 06:18 |
| ralonsoh | at least to decouple the uwsgi usage in the API | 06:19 |
| ykarel | rm_work[m], Thanks for checking, no that functional failure is not tracked yet. But i recall seeing that in past | 06:19 |
| ralonsoh | and your patch need these 3 patches too | 06:19 |
| ralonsoh | because the API need these 3 methods, depending on the service drivers | 06:19 |
| ykarel | Thanks frickler for sharing the background for CI meeting | 06:19 |
| rm_work[m] | ralonsoh: yeah I did a full independent implementation of the fix just to verify, and 90% was already handled in your chain | 06:21 |
| rm_work[m] | you really do handle most of it, I just need SOME way to set workers count without having one of those wsgi servers setting it | 06:21 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Check zuul jobs migration vxlan only required jobs https://review.opendev.org/c/openstack/neutron/+/996388 | 06:44 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: ovn: Remove ``BaseEvent`` and fix ``matches()`` bypassing ``base_match()`` https://review.opendev.org/c/openstack/neutron/+/995945 | 07:58 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2026.1: Fix load_db_migration_drivers https://review.opendev.org/c/openstack/neutron/+/996749 | 07:59 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: [FWaaS] Add basic scenario test for FW attached to L2 ports https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/995695 | 08:01 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Remove unused exception classes https://review.opendev.org/c/openstack/neutron-lib/+/996454 | 08:04 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Remove unused ``DuplicateMeteringRuleInPost`` and ``InvalidPTRZoneConfiguration`` https://review.opendev.org/c/openstack/neutron-lib/+/996455 | 08:04 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: quota: Remove unused ``set_all_quota_usage_dirty()`` https://review.opendev.org/c/openstack/neutron/+/996440 | 08:06 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: [FWaaS] Add basic scenario test for FW attached to L2 ports https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/995695 | 08:07 |
| opendevreview | yatin proposed openstack/neutron master: [CI][FT] Tempoarary skip failing tests centos 10 stream https://review.opendev.org/c/openstack/neutron/+/996753 | 08:55 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-specs master: Add spec for the indirect Floating IPs https://review.opendev.org/c/openstack/neutron-specs/+/996269 | 09:07 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: [FWaaS] Add basic scenario test for FW attached to L2 ports https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/995695 | 09:15 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: [FWaaS] Add basic scenario test for FW attached to L2 ports https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/995695 | 09:57 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: [FWaaS] Add basic scenario test for FW attached to L2 ports https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/995695 | 10:40 |
| opendevreview | Felix Moebius proposed openstack/neutron-lib master: Revert "Set confirm_deleted_rows=False to StandardAttribute obj" https://review.opendev.org/c/openstack/neutron-lib/+/996435 | 10:51 |
| kevko | Hi \o | 10:52 |
| kevko | I would like to ask what is the status of vpnaas in master ..because it not working right now I would say .... 2026.1 is working | 10:53 |
| kevko | Just want to know if anybody knows about the issue whatever it is ..and if there are some patches around ? | 10:53 |
| ralonsoh | kevko, what is the error? | 10:55 |
| kevko | ralonsoh: well, now I deleted my testing master stack ..but what I have is kolla stack in zuul ... | 10:58 |
| kevko | ralonsoh: https://zuul.opendev.org/t/openstack/build/b69a8b563a804a00be6076be977fa0ca | 10:59 |
| kevko | ralonsoh: or debian https://zuul.opendev.org/t/openstack/build/0ec9d207f3294efe890bcd214a9bb3f6 | 10:59 |
| ralonsoh | kevko, I'm not familiar with the kolla logs | 11:05 |
| ralonsoh | can you pinpoint the error? | 11:05 |
| Vii | ERROR stevedore.extension [...] Could not load 'tap-as-a-service': module 'neutron.conf.policies.base' has no attribute 'ADMIN_OR_PROJECT_MEMBER' | 11:09 |
| Vii | Did the RBAC/policies system get reworked in the Neutron master branch recently? | 11:10 |
| Vii | Hi | 11:10 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Check zuul jobs migration vxlan only required jobs https://review.opendev.org/c/openstack/neutron/+/996388 | 11:11 |
| ykarel | Vii, yes https://review.opendev.org/c/openstack/neutron/+/992267 | 11:13 |
| ykarel | and tap-as-a-service was adapted https://review.opendev.org/c/openstack/tap-as-a-service/+/992457 , so you seems missing that | 11:13 |
| Vii | ok, thx | 11:14 |
| mnasiadka | ykarel: adapted but not released, and in Kolla we just install it from pypi from what I see, so we would need to switch to installing from a repo tarball | 11:18 |
| ykarel | mnasiadka, yes , also looks we need to get that all stadium project released as all are updated | 11:23 |
| ykarel | haleyb, ^ | 11:24 |
| kevko | ralonsoh: it looks like vpn gateway is just not created ..I mean like a port for it ..if I am correct | 11:27 |
| kevko | Simply said ..VPN service creation is created in pending and after 3 minutes there is still no gateway IP ...so wondering if some RPC is failing or what ..I can build a master for you and allow connection if you want ... | 11:29 |
| ralonsoh | kevko, the errors in both jobs are different | 11:30 |
| ralonsoh | in debian: http errors | 11:30 |
| ralonsoh | HttpException: 504: Server Error for url: https://192.0.2.10:9696/v2.0/vpn/vpnservices, 504 Gateway Time-out: The server didn't respond in time. | 11:30 |
| ralonsoh | in ubuntu: status: PENDING_CREATE | 11:30 |
| ralonsoh | so the causes are different | 11:31 |
| ralonsoh | I'll try triggering the project CI with a DNM patch | 11:31 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-vpnaas master: DNM == Testing patch, CI execution https://review.opendev.org/c/openstack/neutron-vpnaas/+/996766 | 11:32 |
| kevko | ralonsoh: yeah, thanks | 11:32 |
| ralonsoh | also be aware of the recent changes: | 11:33 |
| ralonsoh | deprecated algoriothms and libreswan updatre | 11:33 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-vpnaas/+/982385 | 11:34 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-vpnaas/+/982383 | 11:34 |
| ykarel | ralonsoh, it could be vpnaas have same issue as taas above i.e https://review.opendev.org/c/openstack/neutron-vpnaas/+/992458 also not released | 11:43 |
| ykarel | if that's true will not hit this issue in devstack jobs | 11:43 |
| ykarel | weekend periodic runs atleast passed https://zuul.openstack.org/buildset/9f35ae92c59a4c338259252d0033b9ad | 11:43 |
| ralonsoh | ykarel, yes, that's right | 11:44 |
| ralonsoh | so as you commented, we need new releases | 11:44 |
| ralonsoh | I'll propose them now | 11:44 |
| ykarel | and if we want to confirm that in devstack we have to try pulling neutron from master | 11:44 |
| ykarel | +1 for release | 11:45 |
| ralonsoh | we have several projects affected: https://review.opendev.org/q/topic:%22bug/2143895%22 | 11:45 |
| ykarel | yes | 11:45 |
| kevko | so was my feelings right : ) ? :) | 11:46 |
| kevko | hmm, neutron-vpnaas is installed from tarball directly in kolla-images | 11:50 |
| ykarel | released tarball or tarball for latest master? | 11:51 |
| opendevreview | yatin proposed openstack/neutron-vpnaas master: [DNM] Check released vpnaas with neutron https://review.opendev.org/c/openstack/neutron-vpnaas/+/996769 | 11:52 |
| ykarel | le's also see if it reproduces in devstack, should help in future | 11:53 |
| kevko | https://tarballs.opendev.org/openstack/neutron-vpnaas/neutron-vpnaas-master.tar.gz | 11:53 |
| ralonsoh | ++ | 11:53 |
| ykarel | ok with ^ tarball it should be some other issue then | 11:53 |
| ykarel | can you also check for tap-as-a-service? | 11:53 |
| ykarel | if that's also master or released? | 11:53 |
| kevko | taas is installed from pip | 11:54 |
| ykarel | ok thx for confirming then vpnaas is different issue | 11:54 |
| ralonsoh | vpnaas kolla jobs are failing not because of the n-lib dependecy | 11:54 |
| ralonsoh | I provide some info upper in this chat | 11:54 |
| slaweq | ralonsoh: ykarel lajoskatona hi, please check https://review.opendev.org/c/openstack/neutron-fwaas/+/995461/ and https://review.opendev.org/c/openstack/neutron-fwaas/+/994674 when you will have some time. I think both are ready for review now | 12:09 |
| slaweq | thx in advance | 12:09 |
| opendevreview | Merged openstack/neutron master: db: Remove OVS monolithic plugin dead migration code https://review.opendev.org/c/openstack/neutron/+/996244 | 12:14 |
| Vii | That "Could not load 'tap-as-a-service': module 'neutron.conf.policies.base' has no attribute 'ADMIN_OR_PROJECT_MEMBER'" error I pasted earlier is actually coming straight from the exact same VPN test | 12:28 |
| Vii | It's really weird though, if Kolla is pulling neutron-vpnaas directly from the master tarball, we shouldn't be seeing this policy attribute crash anymore. Something is definitely off. | 12:29 |
| Vii | https://zuul.opendev.org/t/openstack/build/b69a8b563a804a00be6076be977fa0ca/logs | 12:29 |
| Vii | https://47f87f9b61fa85d35e2c-c0f2790cc4cfdd159ec1860583e90b64.ssl.cf5.rackcdn.com/openstack/b69a8b563a804a00be6076be977fa0ca/primary/logs/kolla/all-ERROR.txt | 12:29 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Check zuul jobs migration vxlan only required jobs https://review.opendev.org/c/openstack/neutron/+/996388 | 12:31 |
| opendevreview | Tristan proposed openstack/ovn-bgp-agent master: Fix test_get_network_vlan_tags against OVN main https://review.opendev.org/c/openstack/ovn-bgp-agent/+/996778 | 12:39 |
| ralonsoh | Vii, that could be related to the eventlet deprecation, we have seen that before with the RPC clients | 12:54 |
| ralonsoh | please open a LP bug | 12:54 |
| ralonsoh | So I've created these releases | 12:55 |
| ralonsoh | https://review.opendev.org/c/openstack/releases/+/996783 | 12:55 |
| ralonsoh | https://review.opendev.org/c/openstack/releases/+/996770 | 12:55 |
| ralonsoh | https://review.opendev.org/c/openstack/releases/+/996768 | 12:55 |
| opendevreview | Merged openstack/neutron master: db: Remove LinuxBridge monolithic plugin dead migration code https://review.opendev.org/c/openstack/neutron/+/996245 | 12:59 |
| haleyb | argh, forgot about meeting, one second | 13:00 |
| haleyb | #startmeeting neutron_drivers | 13:01 |
| opendevmeet | Meeting started Fri Jul 10 13:01:24 2026 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:01 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 13:01 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh, cardoe | 13:01 |
| ralonsoh | hello | 13:01 |
| slaweq | o/ | 13:01 |
| mtomaska | o/ | 13:01 |
| haleyb | there are 3 items on the agenda today | 13:02 |
| haleyb | and i can't remember, but i think we have enough for quorum | 13:03 |
| ralonsoh | we are 3 cores, maybe that's enough | 13:04 |
| cardoe | o/ | 13:04 |
| ralonsoh | (and we can think about expanding this group too) | 13:04 |
| haleyb | we discussed at some point, but either way 3 is what we have and we won't have a tie | 13:05 |
| haleyb | first item is from slaweq | 13:05 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2072505 | 13:05 |
| slaweq | yeah, this is old RFE proposed originally by someone else | 13:05 |
| slaweq | but now I wanted to "revive" it as we also have requests for something like that | 13:06 |
| slaweq | so I am interested in implementing it, at least for ML2/OVN backend | 13:06 |
| slaweq | when it was last time discussed around 2024, there were bunch of questions there, so I already proposed draft of the spec https://review.opendev.org/c/openstack/neutron-specs/+/996269 where I tried to describe proposed approach which I think is the best to address it as well as some alternative solutions | 13:07 |
| slaweq | we have PoC done on devstack already, I've tested it and it works fine for ML2/OVN backend | 13:08 |
| slaweq | if there are any questions now, I'm happy to try to answer them | 13:08 |
| ralonsoh | I have one question about the route checj | 13:08 |
| ralonsoh | `Datapath prerequisites (operator responsibility)` | 13:08 |
| ralonsoh | what does it mean exactly? that the operator need to ensure the routing? | 13:09 |
| ralonsoh | so neutron API won't check it? | 13:09 |
| slaweq | in my proposal not | 13:09 |
| ralonsoh | so you can associate a FIP IP with a router and a private port | 13:10 |
| slaweq | as it may be pretty hard to implement IMO and also, as in use case originally reported in LP - you may have e.g. VM in the middle of this datapath | 13:10 |
| slaweq | in such case it may be even not possible to check it | 13:10 |
| ralonsoh | so, in OVN, you'll create a NAT rule for a private and public IP, but that won't have effect/ | 13:11 |
| ralonsoh | ? | 13:11 |
| slaweq | so with my proposal user can simply associate FIP from external network with ANY port, telling neutron which router should be used for that - the only check neutron do in such case is to ensure that this pointed router have this external net as gateway | 13:11 |
| slaweq | in OVN there is NAT entry created between public and private IP as today, there were no any changes needed there. OVN internally is able to handle it today - at least that's how it worked when I was testing PoC | 13:12 |
| opendevreview | Tristan proposed openstack/ovn-bgp-agent master: Make ARP/NDP IP offset configurable https://review.opendev.org/c/openstack/ovn-bgp-agent/+/996620 | 13:13 |
| ralonsoh | ok, it looks like a "floating" floating IP | 13:13 |
| haleyb | as long as that user has access to that router, i'm assuming you can't choose another projects router - that's what "validates" is implying? | 13:14 |
| haleyb | "The router must exist and be visible to the caller" | 13:14 |
| haleyb | i hadn't read that far | 13:14 |
| ralonsoh | I think we don't check this connectivity | 13:14 |
| ralonsoh | (I think) | 13:14 |
| slaweq | haleyb: of course, if user don't have access to the router there will be 404 returned | 13:14 |
| slaweq | this will be covered with RBAC API policies | 13:15 |
| haleyb | right | 13:15 |
| ralonsoh | ok, RBAC connectivity, not network connectivity | 13:15 |
| slaweq | ralonsoh: today neutron is looking for the router_id for FIP automatically but it needs to find one router where both tenant network and external network are connected | 13:16 |
| ralonsoh | so we do check that there is nested connectivity | 13:16 |
| slaweq | with my proposal we would give users possibility to "overwrite" that behaviour and let user to tell neutron that "I'm smarter then you and you should do as I want" :) | 13:16 |
| slaweq | I'm nost sure what You mean by "nested connectivity" | 13:17 |
| ralonsoh | nah, I'll talk you later because that was my main concern and I don't know to talk via IRC | 13:17 |
| slaweq | there is this method in neutron: https://github.com/openstack/neutron/blob/1240168499cf495b72ea0ac102ef35bcf7422cb1/neutron/db/l3_db.py#L1289 | 13:18 |
| haleyb | from what i understand the external router is just doing dnat/snat and OVN is handling getting it to VM port regardless of what subnet it is on | 13:18 |
| haleyb | it's all just flows... | 13:18 |
| slaweq | and it only looks for single router which provides connectivity between external and tenant networks, if that's not the case it will raise exception | 13:19 |
| slaweq | haleyb: exactly | 13:19 |
| ralonsoh | yes, I know that. Neutron limitation is artificial | 13:19 |
| ralonsoh | ok then, understood | 13:19 |
| slaweq | haleyb: and we already have way to let such "multi hops SNAT" today | 13:19 |
| haleyb | slaweq: so if user has an isoloated subnet, but an external router elsewhere it will work? | 13:19 |
| haleyb | slaweq: yes, we have a flag that should be True to allow it today | 13:20 |
| slaweq | haleyb: I tested it only with multiple routers created in neutron (so LRs in OVN) | 13:20 |
| haleyb | slaweq: ok, so the nested case | 13:20 |
| slaweq | but I didn't try with e.g. vm in the middle. I will need to test that case | 13:21 |
| haleyb | slaweq: i was just thinking nothing in the middle, just an isolated VM | 13:22 |
| haleyb | it's a corner case to be sure | 13:22 |
| haleyb | call it a "castaway VM" on it's own island | 13:23 |
| slaweq | haleyb: you mean in OVN itself? Because I'm not sure I got your question | 13:23 |
| haleyb | slaweq: let me explain. i understand the nested/two-router case where the subnet router does not have external access but the "next" router in the hop does | 13:24 |
| haleyb | that's the case you are talking about in the spec | 13:24 |
| slaweq | ahh, I think I got you - you are asking about something like: vm -- tenant network (isolated, not connected two any router) and then different part where there is router connected to the external network, correct? | 13:25 |
| haleyb | i was just thinking of the corner case of a VM on an isolated network, no router, but thinking now that won't work if i read the spec right | 13:25 |
| slaweq | I didn't test such case :/ | 13:25 |
| slaweq | but probably it won't work | 13:26 |
| slaweq | to make it working in case which I've described in spec I had to configure static routes to other subnet on each router, otherwise packets were not forwarded properly between routers | 13:27 |
| haleyb | i'm guessing some DB lookup will fail and it won't work, but maybe we could explicitly say there needs to be some router locally | 13:27 |
| slaweq | so in case You've described you would probably not be able to configure static routes and it won't work | 13:27 |
| haleyb | slaweq: yes, true. and i'm not saying it should work, just that we should be consistent and maybe add a test | 13:28 |
| slaweq | yes, I was more affraid that it would be bad if it would work | 13:28 |
| slaweq | but I think it won't so all should be good | 13:28 |
| slaweq | please add to the spec comment about such test case, I will for sure add it once working on implementation | 13:29 |
| haleyb | ok, should we vote? although as the iplementor i guess slaweq doesn't get a vote? it feels like a court case where you are arguing the case | 13:30 |
| ralonsoh | +1 to this RFE | 13:31 |
| haleyb | +1 from me as well | 13:31 |
| slaweq | sure, but I guess it would be weird if I would vote agains it though :D | 13:32 |
| haleyb | true :) | 13:32 |
| haleyb | so, as PTL, i'm going to call it approved - i think it's valuable and don't think there is any contention about it, can revisit if someone has issues in the spec | 13:34 |
| slaweq | thx a lot | 13:34 |
| opendevreview | Merged openstack/neutron-fwaas master: Don't update fw group for router ports if it's not needed https://review.opendev.org/c/openstack/neutron-fwaas/+/995461 | 13:34 |
| slaweq | please review spec, I will be on pto for next two weeks but once I will come back I will for sure address all comments there and hopefully start also with implementation | 13:34 |
| haleyb | and technically you are a +1 | 13:35 |
| haleyb | i will review, but am also traveling next week so won't have many extra cycles | 13:35 |
| slaweq | sure, no rush | 13:35 |
| slaweq | as I said, I will not check it for next 2 weeks :) | 13:35 |
| haleyb | enjoy your time off :) | 13:36 |
| slaweq | thx | 13:36 |
| haleyb | ok, next RFE is from ralonsoh | 13:36 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2158981 | 13:36 |
| ralonsoh | [RFE] Support Apache mod_wsgi as an alternative WSGI server for the Neutron API | 13:36 |
| ralonsoh | thanks | 13:36 |
| ralonsoh | there is an ongoing request to use other API runners | 13:36 |
| ralonsoh | right now the Neutron API is tightly coupled to uwsgi | 13:37 |
| ralonsoh | this RFE has 2 goals: | 13:37 |
| ralonsoh | 1. to decouple as much as possible from uwsgo module | 13:37 |
| ralonsoh | 2. implement alternatives, for example for mod_wsgi | 13:37 |
| ralonsoh | patches: https://review.opendev.org/q/topic:%22bug/2158981%22 | 13:37 |
| ralonsoh | for example, in the last one: https://review.opendev.org/c/openstack/neutron/+/995802/4/neutron/common/wsgi_utils.py | 13:38 |
| ralonsoh | `get_api_worker_count` tries uwsgi and mod_wsgi | 13:38 |
| ralonsoh | the other methods are agnostic | 13:38 |
| ralonsoh | as an example of other mnodules: ASGI | 13:38 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/995162/10 | 13:38 |
| cardoe | I’ve made a handful of bugs as well related to running uWSGI without lazy which is related. | 13:38 |
| ralonsoh | implemented on top of these 3 patches | 13:38 |
| ralonsoh | in the related method, this asgi implementation creates its own alternative: https://review.opendev.org/c/openstack/neutron/+/995162/10/neutron/common/wsgi_utils.py | 13:39 |
| cardoe | Neutron can crash without being detected | 13:39 |
| ralonsoh | cardoe, this is now out of scope | 13:39 |
| ralonsoh | so I think this RFE is a must and opens the possibility of other running modules | 13:40 |
| cardoe | It’s the same thing. If you get it working with mod_wsgi it fixes those | 13:40 |
| slaweq | I don't really see any downsides of implementing it | 13:41 |
| slaweq | so it seems pretty straightforward for me | 13:41 |
| ralonsoh | NOTE: the proposed patches must be 100% compatible with the current uWSGI module, just as a heads-up | 13:41 |
| haleyb | i would agree, we had to do some hacking to get mod_wsgi running on gazpacho out of tree | 13:42 |
| ralonsoh | with that we'll be able to have a periodic job, for example | 13:42 |
| ralonsoh | along with the devstack implementation, for sure | 13:42 |
| haleyb | and since we used to support it i think it's good to have it back | 13:42 |
| ralonsoh | so I'll start with the devstack part to use apache+mod_wsgi and implement this CI job | 13:43 |
| ralonsoh | and the documentation | 13:43 |
| ralonsoh | votes? | 13:43 |
| haleyb | so i am +1 to this work | 13:43 |
| slaweq | +1 | 13:44 |
| ralonsoh | thank you folks | 13:44 |
| haleyb | and since it's something others are asking for clearly there is a need, think that counts for something in the voting | 13:45 |
| haleyb | ok, the third one is regarding vpnaas | 13:46 |
| haleyb | not sure if bob is here | 13:46 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2160165 | 13:46 |
| ralonsoh | I'll present it | 13:46 |
| ralonsoh | [RFE] neutron-vpnaas should support ``swanctl`` | 13:46 |
| ralonsoh | So this RFE is proposing the introduction of swanctl support | 13:47 |
| ralonsoh | and after investigating a bit | 13:47 |
| ralonsoh | I realize that is kind of mandatory | 13:47 |
| ralonsoh | from c#1, `impact` section: | 13:47 |
| ralonsoh | The strongSwan project deprecated the stroke plugin and ipsec starter in strongSwan 5.x and has been recommending the VICI interface and swanctl since strongSwan 5.2.0. | 13:47 |
| ralonsoh | We should deprecate the current ipsec starter and switch to swanctl ASAP | 13:48 |
| ralonsoh | this is an RFE but almost mandatory | 13:48 |
| ralonsoh | because this is not mine, I'll say +1 for sure (but I won't be able to implement it) | 13:49 |
| slaweq | I'm definitely not vpnaas expert here so it is hard for me to ask any questions or something like that, but if you are saying you did some research and it seems like mandatory thing to do and if we have someone who is willing to do it, I am good with this | 13:50 |
| slaweq | so I'm +1 on this RFE | 13:50 |
| haleyb | right, i am not an expert either, but seems we need this to support current OS releases | 13:51 |
| haleyb | so I am +1 as well | 13:52 |
| haleyb | the comment from the submittor was "If you have someone to help me through the merge process I'll continue." so hopefully they can do the work | 13:52 |
| ralonsoh | I hope so too because I can't do this right now | 13:53 |
| haleyb | so do we want to support both or just move to the newer? | 13:53 |
| ralonsoh | we should deprecate the existing one | 13:54 |
| ralonsoh | (and move to the new one) | 13:55 |
| haleyb | ok, that is what i was thinking just wanted to confirm | 13:55 |
| haleyb | alright i will update the bugs | 13:56 |
| haleyb | anything else to discuss? | 13:56 |
| haleyb | as a reminder i was going to cancel all the neutron meetings next week if i'm remembering the tuesday meeting notes, as there are a lot of us out | 13:57 |
| ralonsoh | perfect | 13:57 |
| haleyb | ok, thanks for attending, have a nice weekend and time off o/ | 13:57 |
| haleyb | #endmeeting | 13:57 |
| opendevmeet | Meeting ended Fri Jul 10 13:57:55 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:57 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-07-10-13.01.html | 13:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-07-10-13.01.txt | 13:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2026/neutron_drivers.2026-07-10-13.01.log.html | 13:57 |
| ralonsoh | bye | 13:58 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Remove unused firewall v2 exception classes https://review.opendev.org/c/openstack/neutron-lib/+/996456 | 14:02 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Remove unused VPN exception classes https://review.opendev.org/c/openstack/neutron-lib/+/996457 | 14:02 |
| ykarel | ralonsoh, haleyb can you check https://review.opendev.org/c/openstack/neutron/+/996753 | 14:15 |
| opendevreview | Merged openstack/neutron master: Fix load_db_migration_drivers https://review.opendev.org/c/openstack/neutron/+/996632 | 14:16 |
| ralonsoh | sure | 14:16 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: db: Remove IP availability ranges dead migration code https://review.opendev.org/c/openstack/neutron/+/996246 | 14:41 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: db: Remove DVR csnat_l3_agent_bindings dead migration code https://review.opendev.org/c/openstack/neutron/+/996247 | 14:41 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: db: Remove Embrane LBaaS dead migration code https://review.opendev.org/c/openstack/neutron/+/996248 | 14:41 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: db: Remove portbindingports dead migration code https://review.opendev.org/c/openstack/neutron/+/996249 | 14:41 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Check zuul jobs migration vxlan only required jobs https://review.opendev.org/c/openstack/neutron/+/996388 | 15:02 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Add maintenance task for Load_Balancer_Group consistency validation https://review.opendev.org/c/openstack/ovn-octavia-provider/+/996818 | 15:03 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Add a txn id to txn.commit log messages https://review.opendev.org/c/openstack/ovsdbapp/+/996832 | 16:10 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Add TCP and SSL support to venv https://review.opendev.org/c/openstack/ovsdbapp/+/995775 | 16:11 |
| opendevreview | Merged openstack/neutron master: Add agentic coding guidance and docs https://review.opendev.org/c/openstack/neutron/+/996068 | 17:16 |
| gouthamr | haleyb: slaweq ralonsoh: this OSSN could use your review when you get a chance: https://review.opendev.org/c/openstack/security-doc/+/996209 | 17:52 |
| opendevreview | Merged openstack/neutron master: conf: Add missing ``min`` bounds to BGP VRF ID options https://review.opendev.org/c/openstack/neutron/+/995511 | 17:57 |
| rm_work[m] | haleyb: meeting is early for me so wasn't able to make it, but I see ralonsoh mentioned my ASGI request there -- do we think that is covered well enough in the existing RFE to include those 3 lines of ASGI env var reading? or would it require a whole new RFE just for that? (I sincerely hope it will be covered enough) | 18:07 |
| haleyb | rm_work[m]: probably best to ask in one of the reviews as it did not come up | 19:07 |
| rm_work | Hmm ok, was hoping the RFE would be close enough to just kinda lump it in | 19:34 |
| rm_work | It was mentioned during the meeting but yeah the specific question didn’t come up | 19:34 |
| rm_work | The change can also just BE the question, if y’all +2 it or not ;) | 19:35 |
| haleyb | i thought he had dropped a -1/-2 on that change i just haven't kept up with reviews today | 20:13 |
| rm_work[m] | he removed it after I rebased onto his chain | 23:10 |
| rm_work[m] | and explained the limited scope | 23:10 |
| rm_work[m] | (at least I assume it's one of those two reasons, but he did remove the -2) | 23:11 |
| *** haleyb is now known as haleyb|out | 23:35 | |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!