| ykarel | TheJulia, sean-k-mooney thx for checking, if the fix is straight forward and easy we try to get the job back to green, else we or let unmaintained core to disable that job in periodics | 03:47 |
|---|---|---|
| ykarel | in this case looks we can just pin ironic-tempest-plugin as tempest is pinned in that branch/job | 03:48 |
| ykarel | pushed https://review.opendev.org/c/openstack/ironic/+/979773, hope it don't have another issues | 04:15 |
| opendevreview | Takashi Kajinami proposed openstack/neutron master: Adapt to new testtools https://review.opendev.org/c/openstack/neutron/+/979784 | 05:54 |
| opendevreview | Marcin Wilk proposed openstack/neutron master: Fix GW chassis LRP names when added via 'ovn-nbctl' command https://review.opendev.org/c/openstack/neutron/+/979705 | 06:35 |
| ralonsoh | ykarel, slaweq hello! I used https://review.opendev.org/q/topic:%22test_devstack_plugin_tobiko%22 to test the devstack-plugin-tobiko patch, to fix the issue with the Neutron API name. The 2025.1 has the correct "devstack_neutron_service: q-svc". | 08:08 |
| ralonsoh | I'm retesting again this job because something failed. Please check https://review.opendev.org/c/x/devstack-plugin-tobiko/+/979677 | 08:09 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2024.2: Use the `devstack-tobiko` job https://review.opendev.org/c/openstack/neutron/+/977050 | 09:24 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Enable logging API in the fwaas-openvswitch scenario job https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/977780 | 09:31 |
| opendevreview | Merged openstack/neutron-vpnaas-dashboard master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron-vpnaas-dashboard/+/978369 | 09:49 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Fix an issue in the L3 OVN scheduler (2) https://review.opendev.org/c/openstack/neutron/+/978874 | 09:57 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == DNM == OVN L3 scheduler test https://review.opendev.org/c/openstack/neutron/+/978861 | 09:57 |
| opendevreview | OpenStack Proposal Bot proposed openstack/neutron-fwaas-dashboard master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/977395 | 09:58 |
| opendevreview | Maor Blaustein proposed x/whitebox-neutron-tempest-plugin master: Validate minimal podified setup discovered https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/979706 | 10:02 |
| opendevreview | Merged openstack/neutron-fwaas-dashboard master: Bump flake8-import-order https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/977454 | 10:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: All service plugins should inherit from ``ServicePluginBase`` https://review.opendev.org/c/openstack/neutron/+/978898 | 10:12 |
| opendevreview | Merged openstack/neutron-fwaas-dashboard master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/977395 | 10:16 |
| opendevreview | Merged openstack/neutron-vpnaas master: Check that endpoints in endpoint group are unique https://review.opendev.org/c/openstack/neutron-vpnaas/+/964686 | 10:46 |
| opendevreview | Merged openstack/ovn-octavia-provider master: Remove url tags from README https://review.opendev.org/c/openstack/ovn-octavia-provider/+/971732 | 11:20 |
| sean-k-mooney | ralonsoh: i may have missed understood something but i started a conversationon the review https://review.opendev.org/c/openstack/neutron/+/973115/comments/e2d8b369_aa7bd265 | 11:57 |
| sean-k-mooney | tl;dr is i think we shoudl be moduleing "vip" prot with vnic_type=virtual, we shoudl modell the assocation between the vip prot and the relevent host/child port with somethign liek trunk ports or multiple port binding + metadata in the binding, i woudl perfer a top level extion like trunk prot honestly | 11:59 |
| sean-k-mooney | i think any interaction between port a and port b based on the ip adress of port b being in port a's allowed adress paris expeically if it cause the mech driver to rebind the port is problematic | 12:00 |
| sean-k-mooney | it also seam liek there is a desire to allow floating ips to be asoscated with the vip port and have that natd, unless im mistaken that was not a think wiht ml2/ovs or ml2/sriov_nic_agent and is a new fetacure which is definetlly supprotable but i am not convidece the current patch is the right way. it think it need to be a first class extention. with all that said im | 12:03 |
| sean-k-mooney | somewhat out of the loop on neutron developemnt these days but i was pretty surpised that this was beign treated as a bug and didnt have a spec. | 12:03 |
| sean-k-mooney | i also might be missuderstanding the change and the problem staemtnt but that my perspective | 12:03 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Fix an issue in the L3 OVN scheduler (2) https://review.opendev.org/c/openstack/neutron/+/978874 | 12:18 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == DNM == OVN L3 scheduler test https://review.opendev.org/c/openstack/neutron/+/978861 | 12:18 |
| ralonsoh | sean-k-mooney, I'm not sure about the VIP to FIP association you are talking | 12:26 |
| ralonsoh | about the VNIC type, that could be something to be considered | 12:26 |
| ralonsoh | in trunk ports, the vnic type of the parent ports is the same as the subports | 12:26 |
| ralonsoh | in ML2/OVN the subports are just logical representations, in ML2/OVS, we had actual TAP devices | 12:27 |
| ralonsoh | but for virtual ports, I think we can consider the VNIC_TYPE=virtual | 12:27 |
| ralonsoh | of course, we would need to refactor how we update the host id information | 12:28 |
| ralonsoh | sean-k-mooney, why vif_type=virtual is not ok for you? | 12:28 |
| ralonsoh | about the spec, yes, this has entity enough to be considered in a spec | 12:29 |
| sean-k-mooney | sorry on downstream call ill reploy after | 12:31 |
| opendevreview | Merged openstack/neutron-fwaas master: [Docs] Add comparison of various fwaas drivers https://review.opendev.org/c/openstack/neutron-fwaas/+/979658 | 12:54 |
| opendevreview | Luca Del Monte proposed openstack/ovn-octavia-provider master: Fix LB association to wrong routers on LRP events https://review.opendev.org/c/openstack/ovn-octavia-provider/+/976236 | 13:05 |
| sean-k-mooney | ralonsoh: i may not be understandign the propsoed change but im concerned by how we identify which prot is bound to the new vif_type. since vif types are not requested they are determind by the mech driver that binds the port | 13:07 |
| opendevreview | Merged openstack/neutron-fwaas master: [Docs] Add documentation describing internals of each fwaas driver https://review.opendev.org/c/openstack/neutron-fwaas/+/979659 | 13:07 |
| opendevreview | Merged openstack/neutron-fwaas master: [Docs] Add short info about configuration files in the FWaaS docs https://review.opendev.org/c/openstack/neutron-fwaas/+/979660 | 13:07 |
| opendevreview | Merged openstack/neutron-fwaas master: [Docs] Add user docs for the FWaaS usage https://review.opendev.org/c/openstack/neutron-fwaas/+/979661 | 13:07 |
| sean-k-mooney | ralonsoh: woudl you have time to chat about this perhaps on a video call quickly when you are free | 13:07 |
| sean-k-mooney | ralonsoh: by the way my concewrn is not with vif_type=virtual in gneral its with "Used for binding virtual ports, e.g. ports referenced in | 13:27 |
| sean-k-mooney | allowed-address-pairs for other ports." | 13:27 |
| sean-k-mooney | determining which prot is a virtual prot based on teh allowed-address-pairs or other port i think is not ok | 13:28 |
| ralonsoh | sean-k-mooney, sure, today I can't join a video call because I have meetings | 13:43 |
| ralonsoh | tomorrow morning at any time, ping me and I'll join a video call | 13:43 |
| ralonsoh | sean-k-mooney, in any case, we are not going to merge this patch in the release at this point | 13:44 |
| otherwiseguy | sean-k-mooney: ralonsoh: I just joined and missed the first part of the convo, but this sounds related to a patch I wrote a while back. | 13:44 |
| ralonsoh | so we have time to discuss it | 13:44 |
| ralonsoh | otherwiseguy, https://review.opendev.org/c/openstack/neutron/+/973115 | 13:44 |
| otherwiseguy | ralonsoh: thanks | 13:44 |
| sean-k-mooney | well its also realted to a prir change | 13:45 |
| sean-k-mooney | but that is the patch (well really the addtion of the vif type) that brought it to my attention | 13:45 |
| ralonsoh | the alternative proposal, making the retries, was IMO worse | 13:49 |
| ralonsoh | so having a way to determine that a port is virtual makes everything easier | 13:49 |
| sean-k-mooney | yep it does im just saying that allowed_adress_pair is not a good way to do that | 13:54 |
| sean-k-mooney | espically allowed aress pair on a diffent prot then the virutal one | 13:54 |
| opendevreview | Merged openstack/neutron-vpnaas master: Fix ipsec config updates https://review.opendev.org/c/openstack/neutron-vpnaas/+/976135 | 13:57 |
| ralonsoh | sean-k-mooney, but you can have the same IP address in several allowed address pair in different ports | 13:57 |
| sean-k-mooney | yep you can | 13:58 |
| ralonsoh | for example, if you have a HA service inside several VMs | 13:58 |
| ralonsoh | so why AAP is not a good way to do it? | 13:58 |
| ralonsoh | anyway, we have the Neutron meeting in 2 minutes | 13:58 |
| sean-k-mooney | ack | 13:58 |
| ralonsoh | we can sync on video | 13:58 |
| lajoskatona | ralonsoh: Hi, do we have meeting today as haleyb is out? | 14:03 |
| slaweq | lajoskatona I was going to ask the same :) | 14:04 |
| ralonsoh | ups yes | 14:04 |
| lajoskatona | :-) | 14:04 |
| ralonsoh | I was in charge | 14:04 |
| ralonsoh | one sec | 14:04 |
| ralonsoh | #startmeeting networking | 14:04 |
| opendevmeet | Meeting started Tue Mar 10 14:04:41 2026 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:04 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:04 |
| opendevmeet | The meeting name has been set to 'networking' | 14:04 |
| ralonsoh | Sorry folks | 14:04 |
| ralonsoh | Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, haleyb, ralonsoh | 14:04 |
| lajoskatona | o/ | 14:04 |
| slaweq | o/ | 14:04 |
| fungi | ahoy! | 14:04 |
| bcafarel | o/ | 14:05 |
| rubasov | o/ | 14:05 |
| ralonsoh | #topic announcements | 14:05 |
| ralonsoh | Hello all | 14:05 |
| ralonsoh | let's start | 14:05 |
| ralonsoh | #link https://releases.openstack.org/gazpacho/schedule.html | 14:05 |
| cbuggy | o/ | 14:05 |
| ralonsoh | this is the RC1 week | 14:05 |
| ralonsoh | the releases patches are in gerrit now | 14:06 |
| slaweq | yeap | 14:06 |
| slaweq | I've checked them today | 14:06 |
| ralonsoh | #link https://review.opendev.org/c/openstack/releases/+/979572 | 14:06 |
| slaweq | and -1 some to wait for few patches | 14:06 |
| ralonsoh | and the other projects too | 14:06 |
| slaweq | but I also wanted to ask here about few of them | 14:06 |
| ralonsoh | yes, please check every project in https://review.opendev.org/q/project:openstack/releases and check is there is any missing patch | 14:06 |
| slaweq | ralonsoh should I ask now or wait until you will finish announcements? | 14:07 |
| ralonsoh | please go on | 14:07 |
| slaweq | ok, thx | 14:07 |
| slaweq | so for neutron - do we have any patches which we want to wait for? | 14:08 |
| slaweq | I was thinking about those: https://review.opendev.org/c/openstack/neutron/+/978838 | 14:08 |
| slaweq | https://review.opendev.org/c/openstack/neutron/+/978963 | 14:08 |
| slaweq | https://review.opendev.org/c/openstack/neutron/+/978835 | 14:08 |
| slaweq | wdyt? | 14:08 |
| ralonsoh | Jakub is not present... | 14:08 |
| ralonsoh | yes, the project_id migration patches should be merged today | 14:08 |
| ralonsoh | and about the bgp patches, I would like to talk to Jakub | 14:09 |
| ralonsoh | I know there are at least 3 pending ones | 14:09 |
| slaweq | you mean ovn-bgp-agent's patches? | 14:09 |
| slaweq | or neutron-dynamic-routing ones? | 14:09 |
| ralonsoh | Neutron ovn-bgp patches | 14:09 |
| ralonsoh | not n-d-r | 14:09 |
| lajoskatona | for n-d-r I stopped the release: https://review.opendev.org/c/openstack/releases/+/979563 also to wait for https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/977670 | 14:09 |
| slaweq | thx lajoskatona, yes I saw that | 14:10 |
| ralonsoh | so we need the neutron patch too to merge the n-d-r one | 14:10 |
| slaweq | for ovn-bgp-agent I talked with dalvarez today as he is owner of many of those patches and he told me that we don't need to wait for them now | 14:10 |
| lajoskatona | I hhope haleyb's patches for project_is will be green now and the n-d-r patch also can be merged | 14:10 |
| lajoskatona | ralonsoh: yes, that's right | 14:11 |
| ralonsoh | ok, after this meeting I'll check the networking releases and check all pending patches too | 14:11 |
| ralonsoh | also check those ones with priority => 1 | 14:11 |
| slaweq | there is also one open patch for networking-sfc: https://review.opendev.org/c/openstack/networking-sfc/+/972672 - do we want to wait for it few more days? | 14:12 |
| slaweq | lajoskatona it is your patch | 14:12 |
| ralonsoh | sfc tox jobs should be fixed now | 14:13 |
| slaweq | and is still failing unit tests jobs AFAICS | 14:13 |
| lajoskatona | it 's not gate fixing, I can check it (had no time today) so we can go without it | 14:13 |
| ralonsoh | ok, the error is caused by the patch | 14:13 |
| lajoskatona | (I just saw some warnings in the logs as I remember) | 14:13 |
| lajoskatona | (no actually haleyb saw the logs see : https://bugs.launchpad.net/neutron/+bug/2131969 ) | 14:14 |
| ralonsoh | I think we are in time to merge it this week and release it | 14:14 |
| ralonsoh | ok, any other comment about the releases? | 14:15 |
| lajoskatona | ack, I check than and make it green (sfc) | 14:15 |
| ralonsoh | Remember that the PTG is in 1 month, April 20-24 | 14:16 |
| ralonsoh | you can register in https://openinfra.org/ptg/ | 14:16 |
| ralonsoh | I'll talk to haleyb|out in order to have the etherpad ready | 14:16 |
| ralonsoh | something you want to add? | 14:17 |
| ralonsoh | ok, let's move on | 14:17 |
| ralonsoh | #topic bugs | 14:17 |
| ralonsoh | slaweq, was the bug deputy | 14:17 |
| ralonsoh | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QSKBWAYLL2WO3LPTKJ4WILQ2WEFRUE4W/ | 14:17 |
| ralonsoh | I've reviewed the listed bugs and only one is still not assigned | 14:18 |
| ralonsoh | #link bugs.launchpad.net/neutron/+bug/2143560 | 14:18 |
| ralonsoh | Optimization: create a bulk operation for ``_create_port_security_group_binding`` | 14:18 |
| ralonsoh | this is just a possible optimization I saw when debugging another issue | 14:18 |
| ralonsoh | feel free to take it if you have 1-2 hours free | 14:18 |
| ralonsoh | any other bug to be discussed? | 14:19 |
| ralonsoh | This week rubasov is the deputy, next week is haleyb | 14:19 |
| rubasov | on it | 14:19 |
| ralonsoh | thanks! | 14:19 |
| rubasov | of course | 14:19 |
| ralonsoh | next topic | 14:19 |
| ralonsoh | #topic specs | 14:20 |
| ralonsoh | #link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open | 14:20 |
| ralonsoh | last week we merged the PVLAN one | 14:20 |
| ralonsoh | we should not merge new ones until the new cycle but we can review them | 14:20 |
| ralonsoh | I need to check the first one that is the most active oen | 14:20 |
| ralonsoh | any other comment? | 14:21 |
| ralonsoh | #topic community-goals | 14:21 |
| ralonsoh | We have the neutronclient deprecation | 14:21 |
| ralonsoh | @lajoskatona, any update? | 14:22 |
| lajoskatona | no | 14:22 |
| lajoskatona | the nova team waits till begining of H to start merging / reviewing patches | 14:22 |
| lajoskatona | to be ready I plan to push the reamining part of the series | 14:22 |
| ralonsoh | ok, maybe Nova folks won't merge anything at this point | 14:23 |
| ralonsoh | but at least we can have reviews | 14:23 |
| ralonsoh | this must be a topic for the PTG, if we still have these patches under review | 14:23 |
| ralonsoh | #link https://review.opendev.org/q/topic:%22sdk_for_neutron%22 | 14:24 |
| lajoskatona | yes, good idea, I can add it to nova etherpad | 14:24 |
| ralonsoh | perfect | 14:24 |
| ralonsoh | thanks lajoskatona | 14:24 |
| ralonsoh | any other update? | 14:24 |
| lajoskatona | slightly related but I pushed patch for moving cli code from neutronclient to osc | 14:25 |
| lajoskatona | https://review.opendev.org/q/topic:%22migrate_stadium_osc%22 | 14:25 |
| lajoskatona | for bgpvpn | 14:25 |
| ralonsoh | perfect, we need first the OSC code merged | 14:26 |
| ralonsoh | thanks a lot for your time on this! | 14:26 |
| lajoskatona | it was a bad decision as bgpvpn CLI code is really ugly, so Stephen is very happy with it :-) but I have reviews on the good side :-) | 14:26 |
| lajoskatona | yes we need osc | 14:26 |
| slaweq | I am going to start working on similar patch for fwaas plugin | 14:26 |
| lajoskatona | I hope other plugins will be easier | 14:27 |
| lajoskatona | slaweq: cool | 14:27 |
| ralonsoh | nice | 14:27 |
| slaweq | The lajoskatona for doing it as this will be helpful for me for sure | 14:27 |
| ralonsoh | at least we don't have a deadline for it, we can continue during the next release | 14:27 |
| slaweq | *thx | 14:27 |
| ralonsoh | so let's move to the last topic | 14:28 |
| ralonsoh | #topic on-demand | 14:28 |
| ralonsoh | please fungi | 14:28 |
| fungi | this is the followup for bridging the gap flamingo cycle retrospective | 14:28 |
| fungi | this effort started with representatives from member organizations sharing frustrations with, primarily, their employees' experiences trying to contribute patches in various openstack projects | 14:28 |
| fungi | investigating these reports on a case-by-case basis, foundation staff concluded most misunderstandings were due to mismatched expectations arising from incomplete communication or silence (and not necessarily on the part of the maintainers) | 14:29 |
| fungi | what we've observed from successful exchanges in some projects is that increasing communication effectiveness ultimately leads to improved efficiency and time savings for all parties involved; some examples include: | 14:29 |
| fungi | documenting review priorities and the prioritization process, as well as publicizing it more (e.g. with pointers in review comments), so that change owners know the priority for their own work and how to get involved in that decision | 14:29 |
| fungi | proactively communicating reviewer availability, changes in availability, and explicit handoff to other reviewers, so that change owners know how long they might be waiting (and encouraging them to communicate their own availability) | 14:29 |
| fungi | overall clearer communications with change owners, for example avoiding heavy reliance on acronyms and team-specific jargon, since english is not the primary language for a majority of our community and their familiarity with it varies | 14:29 |
| fungi | to this end, i and other community managers on the foundation staff are working on putting together some materials that we hope teams will find useful, and will collaborate with us to help improve and expand further | 14:29 |
| fungi | ildiko sent an update about this to openstack-discuss a few minutes ago: | 14:29 |
| fungi | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/BKVQ3CCFKQAUJ2TFOO6UWRQPFOGFRRBV/ Ideas to improve contributor and maintainer experience | 14:29 |
| fungi | one thing we want to try is cut-and-paste review response templates for common situations; the vulnerability management team has used similar techniques for bug triage and assembling advisories, and they've found it saves a lot of time | 14:29 |
| fungi | another is assembling contributor and reviewer checklists to help avoid common pitfalls and anti-patterns, based on all of the earlier focus group feedback and brainstorming sessions we held with the community in 2024 | 14:29 |
| fungi | something else we want to try is collaborating to produce case studies with companies who have been investing in project maintenance work and whose employees have a track record of successful contribution patterns | 14:30 |
| fungi | we also plan to continue identifying additional tactics and strategies that teams have positive experiences with, to see if there's a way they can be generalized for adoption by other teams facing similar challenges | 14:30 |
| fungi | if anybody has follow-up thoughts or questions on any of the above, as well as for the survey and metrics analysis from last week now that you've had time to mull it over, i'm happy to answer questions and entertain feedback here | 14:30 |
| fungi | (or in irc after the meeting, or on the openstack-discuss mailing list, or even directly/in private for that matter) | 14:30 |
| ralonsoh | that would be nice, during the PTG, to have an output from the Neutron team | 14:31 |
| ralonsoh | I'll review the link you provided (https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/BKVQ3CCFKQAUJ2TFOO6UWRQPFOGFRRBV/) | 14:31 |
| ralonsoh | and yes, we should make that public to improve our code quality, speed up reviews, maintain code, etc | 14:31 |
| fungi | yeah, that would be a good place to follow up, i'd love to see more teams thinking about these things as we roll into the ptg | 14:32 |
| ralonsoh | I'll talk to the PTL next week (his is OOO now) | 14:32 |
| fungi | and we should have the next round of surveys ready to go soon for the gazpacho retrospective, so that's a good time to remind teammates to fill it out | 14:32 |
| ralonsoh | I would like to improve, somehow, our review strategy and add more people to that | 14:33 |
| lajoskatona | +1 | 14:34 |
| ralonsoh | thanks fungi for bringing this topic here | 14:34 |
| fungi | clearly communicating how review activity is being prioritized by maintainers in theory may help to remind other contributors that getting involved in maintainer activities and helping set goals and priorities is an effective way to get their work merged too | 14:35 |
| ralonsoh | yeah, personally I need first to define a priority board for myself | 14:36 |
| ralonsoh | but that's ok, that's how it should be | 14:36 |
| fungi | none of this is ever easy, of course | 14:36 |
| ralonsoh | ok, any other topic you want to bring here? | 14:37 |
| fungi | doesn't sound like there are any more questions at the moment? you all know where to find me if you think of more | 14:37 |
| ralonsoh | thanks | 14:38 |
| ralonsoh | ok, folks, I think we can close for today | 14:38 |
| ralonsoh | #endmeeting | 14:38 |
| opendevmeet | Meeting ended Tue Mar 10 14:38:49 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:38 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2026/networking.2026-03-10-14.04.html | 14:38 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2026/networking.2026-03-10-14.04.txt | 14:38 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2026/networking.2026-03-10-14.04.log.html | 14:38 |
| ralonsoh | bye | 14:38 |
| slaweq | o/ | 14:39 |
| wilkmarcin | o/ | 14:39 |
| lajoskatona | Bye | 14:39 |
| wilkmarcin | I know everyone is busy with the pending release tasks, but I'd appreciate it if you could take a look at https://review.opendev.org/c/openstack/neutron/+/979705, if you find some time. Thank you! | 14:40 |
| ralonsoh | let me check | 14:41 |
| wilkmarcin | thx | 14:41 |
| blanson[m] | Hello, sorry to bother you guys with this, but we're seeing some weird behavior in neutron epoxy (and earlier). We have a vxlan network with public subnets that are advertised through a provider network to our switches. This vxlan network is used to provide public IPs to lots and lots of VMs in the same project.With a test instance, we're seeing unicast traffic from other instances on the same compute node as us, tho we believe | 15:03 |
| blanson[m] | this shouldn't happen. I just wanted to know if you would maybe have an explanation for this ? or if we're doing something obviously wrong ? | 15:03 |
| opendevreview | Merged openstack/neutron master: Remove dead code: method ``_subprocess_setup`` https://review.opendev.org/c/openstack/neutron/+/979307 | 15:04 |
| opendevreview | Merged openstack/neutron master: [Docs] Remove FWaaS scenario document https://review.opendev.org/c/openstack/neutron/+/979666 | 15:04 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 15:07 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 15:07 |
| ralonsoh | blanson[m], sorry, I don't understand the issue here. You have a VXLAN network and this network has several subnets. But how are you connecting this VXLAN network to the provider network? | 15:18 |
| ralonsoh | what backend are you using? ML2/OVN? ML2/OVS? | 15:18 |
| blanson[m] | We're using ML2/OVS. this vxlan network has multiple subnets, which have neutron routers with their gateways in the provider network. The provider network is a VLAN strictly between network nodes and switches to advertise the IP addresses from the vxlan network to the backbone | 15:23 |
| slaweq | ralonsoh ykarel hi, please check https://review.opendev.org/c/openstack/neutron/+/978060 when you will have a minute | 15:34 |
| slaweq | lajoskatona I think that it should be good to go now as neutron-lib changes will be in 2026.1 | 15:34 |
| opendevreview | Merged x/whitebox-neutron-tempest-plugin master: Validate minimal podified setup discovered https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/979706 | 15:36 |
| lajoskatona | slaweq: you mean for https://review.opendev.org/c/openstack/neutron/+/978060 ? | 15:55 |
| slaweq | lajoskatona yes | 15:57 |
| opendevreview | Lajos Katona proposed openstack/networking-sfc master: Handle missing VLAN in _setup_egress_flow_rules https://review.opendev.org/c/openstack/networking-sfc/+/972672 | 16:19 |
| lajoskatona | slaweq, ralonsoh: for fwaas release: some doc patches from slaweq were merged, so the hash can be updated with those also | 16:26 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP bgp: Fix functional test failures for gateway IP reconciliation https://review.opendev.org/c/openstack/neutron/+/979878 | 16:52 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: bgp: Connect provider switch when created https://review.opendev.org/c/openstack/neutron/+/978155 | 17:30 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Implement BGP resources deletion https://review.opendev.org/c/openstack/neutron/+/979286 | 17:31 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 17:31 |
| opendevreview | Merged openstack/neutron master: Use project_id key in security group plugin code https://review.opendev.org/c/openstack/neutron/+/978835 | 17:34 |
| opendevreview | Merged openstack/neutron master: Use project_id key in address scope and subnetpool plugin code https://review.opendev.org/c/openstack/neutron/+/978838 | 17:37 |
| vinetos | Hello ! I was digging under the hood of networking and I notice that I my recent setup (Epoxy, ML2/OVS), I cannot see any of the qvo / qbr pair interfaces on my computes. I only see an tap interfaces. Is it a change in networking or I messed my setup ? I can see them in my old setup (Wallaby, ML2/OVS) | 18:19 |
| sean-k-mooney | vinetos: that is the toplogy that is created when your using the ovs firewall driver instead of iptables | 18:22 |
| sean-k-mooney | the legacy approch used a linux bridge where the tap was added to allow iptabels ruels to be enforced on the tap | 18:23 |
| sean-k-mooney | since they are not enforced if a tap is directly added to ovs | 18:23 |
| sean-k-mooney | in leater release i think the openvswich openflow/connection tracker firewall became the defualt | 18:23 |
| sean-k-mooney | in that toplocy the port id directly added to the br-int | 18:24 |
| sean-k-mooney | since we dont ahve the limitation of iptabels | 18:24 |
| vinetos | Oh I see. It makes sense | 18:25 |
| vinetos | Thanks | 18:26 |
| sean-k-mooney | there is a setting for this in the ml2_conf.ini i think | 18:26 |
| sean-k-mooney | its somethign like security_group_driver | 18:26 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: functional: Pin used compiled OVS and OVN versions https://review.opendev.org/c/openstack/neutron/+/961243 | 18:37 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: func: Workaround LSP bind command https://review.opendev.org/c/openstack/neutron/+/979895 | 18:37 |
| opendevreview | Merged openstack/neutron master: Use project_id key in floating IP plugin code https://review.opendev.org/c/openstack/neutron/+/978963 | 19:29 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: func: Avoid using name2 from PB.external_ids https://review.opendev.org/c/openstack/neutron/+/979274 | 20:51 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: func: Workaround LSP bind command https://review.opendev.org/c/openstack/neutron/+/979895 | 20:51 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: functional: Pin used compiled OVS and OVN versions https://review.opendev.org/c/openstack/neutron/+/961243 | 20:51 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: func: Remove skipping BGP tests https://review.opendev.org/c/openstack/neutron/+/978797 | 20:51 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!