| opendevreview | Merged openstack/neutron master: [FT] Improve ``test_assert_pings_during_br_phys_setup_not_lost*`` tests https://review.opendev.org/c/openstack/neutron/+/952209 | 00:41 |
|---|---|---|
| opendevreview | Merged openstack/python-neutronclient master: Add warning for using the python bindings https://review.opendev.org/c/openstack/python-neutronclient/+/947816 | 01:25 |
| opendevreview | Merged openstack/neutron master: Allow empty gateway IP in subnets from subnet pools https://review.opendev.org/c/openstack/neutron/+/952335 | 01:49 |
| opendevreview | Merged openstack/neutron master: Consume DuplicatedHANetwork constant from neutron-lib https://review.opendev.org/c/openstack/neutron/+/947184 | 01:53 |
| opendevreview | Merged openstack/neutron master: Move the ``ProcessMonitor`` initialization to the ``Service.start`` phase https://review.opendev.org/c/openstack/neutron/+/952450 | 02:48 |
| opendevreview | yatin proposed openstack/neutron-tempest-plugin master: [CI][2025.1] Skip more failing test in ubuntu jammy ovn job https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/952546 | 06:03 |
| *** elodilles_ooo is now known as elodilles | 06:08 | |
| opendevreview | Renjing Xiao proposed openstack/neutron-tempest-plugin master: Randomize second octet to avoid test vlan IP collision https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/951095 | 06:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: [FT] Improve ``test_assert_pings_during_br_phys_setup_not_lost*`` tests https://review.opendev.org/c/openstack/neutron/+/952551 | 06:42 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2024.2: [FT] Improve ``test_assert_pings_during_br_phys_setup_not_lost*`` tests https://review.opendev.org/c/openstack/neutron/+/952552 | 06:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2024.1: [FT] Improve ``test_assert_pings_during_br_phys_setup_not_lost*`` tests https://review.opendev.org/c/openstack/neutron/+/952553 | 06:43 |
| lajoskatona | sean-k-mooney, ralonsoh: Hi, quick question regarding os-vif backports, for https://review.opendev.org/c/openstack/os-vif/+/949736 , what do you think about backporting this patch for example? | 08:27 |
| lajoskatona | sean-k-mooney, ralonsoh: without bumping requirements in old branches it will not affect nova for example (not sure if we can expect stable releases for os-vif for example at all), but can be useful for folks running into it in the wild | 08:29 |
| opendevreview | Merged openstack/neutron master: osdb: remove usage of eventlet in dbhandler https://review.opendev.org/c/openstack/neutron/+/940983 | 08:32 |
| ralonsoh | lajoskatona, it is possible to update the stable libraries and then bump the requirements | 08:46 |
| ralonsoh | in case of bugs, so I think this is feasible | 08:46 |
| lajoskatona | ralonsoh: ack, than I do the backport | 08:59 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: Execute ``test_initialize_network...`` with concurrency 1 https://review.opendev.org/c/openstack/neutron/+/952557 | 09:17 |
| opendevreview | yatin proposed openstack/neutron-tempest-plugin master: [CI][2025.1] Skip more failing test in ubuntu jammy ovn job https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/952546 | 09:30 |
| opendevreview | Renjing Xiao proposed openstack/neutron-tempest-plugin master: Randomize second octet to avoid test vlan IP collision https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/951095 | 09:36 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: WIP == Add state reporting back to metadata agents https://review.opendev.org/c/openstack/neutron/+/952561 | 09:50 |
| ralonsoh | haleyb, hello! Ping me when available (https://review.opendev.org/c/openstack/neutron/+/952399) | 09:51 |
| ralonsoh | no rush | 09:51 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: Allow empty gateway IP in subnets from subnet pools https://review.opendev.org/c/openstack/neutron/+/952562 | 09:52 |
| seba | as the bpgvpn service type registering has been merged ( https://review.opendev.org/c/openstack/networking-bgpvpn/+/950212 ) I have two more which are very similar for two other extensions: fwaas https://review.opendev.org/c/openstack/neutron-fwaas/+/950202 and vpnaas https://review.opendev.org/c/openstack/neutron-vpnaas/+/950529 | 10:09 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2024.2: Allow empty gateway IP in subnets from subnet pools https://review.opendev.org/c/openstack/neutron/+/952564 | 10:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2024.1: Allow empty gateway IP in subnets from subnet pools https://review.opendev.org/c/openstack/neutron/+/952565 | 10:11 |
| sean-k-mooney | lajoskatona: we could backprot it but ya if there is a dep on neutron or other libs to also have backports then we would need to do them all in lockstep | 10:14 |
| lajoskatona | sean-k-mooney: I think the critical point is to update req files in stable (perhaps highlighted with red flaming letters somewhere in the backport policy doc :-)) | 10:19 |
| opendevreview | Lajos Katona proposed openstack/os-vif stable/2025.1: OVS Trunk: Add bridge_name to external_ids https://review.opendev.org/c/openstack/os-vif/+/952567 | 10:20 |
| sean-k-mooney | lajoskatona: well updating requirement files is not an option | 10:48 |
| sean-k-mooney | lajoskatona: we cant raise min versions | 10:48 |
| sean-k-mooney | lajoskatona: on the os-vif side i dont see any depency change, the new behavior jsut add a new external id, the bridge | 10:49 |
| sean-k-mooney | so that shoudl be fine to back port, the neutron side of it however is probaly more inovlved | 10:49 |
| sean-k-mooney | if you want to backport it you have to assume it could be an old version of os-vif so you cant driectly delete the old code it has to work with both but work better if the backport is there | 10:50 |
| sean-k-mooney | if the neutron patches have a hard dep on the new behaivor its not backporatable by definion on the neutron side | 10:52 |
| opendevreview | Merged openstack/neutron master: Execute ``test_initialize_network...`` with concurrency 1 https://review.opendev.org/c/openstack/neutron/+/952193 | 11:12 |
| opendevreview | Merged openstack/neutron master: Consider logging options when using OVNdbsync https://review.opendev.org/c/openstack/neutron/+/948783 | 11:12 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add deprecation warning for the OVN Metadata agent https://review.opendev.org/c/openstack/neutron/+/952319 | 11:16 |
| lajoskatona | sean-k-mooney: the os-vif change is standalon from Neutron perspective luckily, I added only some code documentation for future ones who dig that part of the code | 11:19 |
| haleyb | ralonsoh: hi, just read your comment about backporting that to 2025.1, had forgotten about oslo.service dependency | 13:36 |
| ralonsoh | haleyb, yeah, this is a problem | 13:37 |
| ralonsoh | I've proposed a possible backport | 13:37 |
| ralonsoh | If we accept that, we can fix it in 2025.1 | 13:37 |
| haleyb | ralonsoh: i'm fine with making our own copy of FixedIntervalLoopingCall | 13:38 |
| ralonsoh | perfect then | 13:39 |
| haleyb | what did you want me to change with the commit message? | 13:39 |
| ralonsoh | yeah, much better | 13:39 |
| ralonsoh | then I'll update the backport too | 13:39 |
| haleyb | ralonsoh: let me update the commit message and let me know if you are ok with it, one minute... | 13:40 |
| opendevreview | Brian Haley proposed openstack/neutron master: Add state reporting back to metadata agents https://review.opendev.org/c/openstack/neutron/+/952399 | 13:42 |
| haleyb | ralonsoh: let me know, or feel free to propose a change | 13:43 |
| ralonsoh | sure | 13:43 |
| ralonsoh | cool for me | 13:43 |
| haleyb | ralonsoh: the only missing piece is it's untested from a functional perspective, i just didn't see any place obvious to do that | 13:45 |
| ralonsoh | haleyb, yes, this is a big testing gap | 13:46 |
| ralonsoh | also the agents status report | 13:46 |
| haleyb | agreed | 13:48 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: Add state reporting back to metadata agents https://review.opendev.org/c/openstack/neutron/+/952561 | 13:48 |
| haleyb | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Jun 13 14:00:13 2025 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, haleyb, ralonsoh | 14:00 |
| mlavalle | \o | 14:00 |
| slaweq | o/ | 14:00 |
| ralonsoh | hello | 14:00 |
| jimin3shin[m] | Hello | 14:00 |
| lajoskatona | o/ | 14:01 |
| haleyb | there was only one item on the agenda, Dai said he would join | 14:01 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2112446 | 14:01 |
| jimin3shin[m] | I added my rfe on the agenda. Is that not going to be discussed today? | 14:02 |
| haleyb | jimin3shin[m]: i don't see it on the agenda, unless i have the wrong nick for you? | 14:03 |
| ralonsoh | https://wiki.openstack.org/wiki/Meetings/NeutronDrivers | 14:03 |
| ralonsoh | nothing there | 14:03 |
| ralonsoh | let's first discuss the open topic | 14:04 |
| ralonsoh | daidv, hello! | 14:04 |
| daidv2 | Hi ralonsoh | 14:04 |
| jimin3shin[m] | ralonsoh: It's in the "Ready for discussion" section. | 14:05 |
| ralonsoh | please, present your RFE | 14:05 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: [CI][2025.1] Skip more failing test in ubuntu jammy ovn job https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/952546 | 14:06 |
| haleyb | jimin3shin[m]: i see it now, can talk about it after the current one from daidv2 | 14:06 |
| jimin3shin[m] | Okay, thank you! | 14:06 |
| haleyb | daidv2: can you give an overview of your RFE? | 14:07 |
| haleyb | i don't know if he's having connection issues | 14:08 |
| mlavalle | he is having trouble with the connection | 14:09 |
| haleyb | so maybe we can discuss jimin3shin[m]'s RFE while that is figured out | 14:09 |
| daidv | sorry ralonsoh , i was quited | 14:09 |
| daidv | I'm online now | 14:10 |
| haleyb | daidv: great | 14:10 |
| daidv | So, can we discuss about my propose first or ? | 14:11 |
| mlavalle | yes | 14:11 |
| mlavalle | go ahead | 14:11 |
| haleyb | daidv: yes, since you're back online we can discuss your's | 14:11 |
| daidv | Oki, normally, openstack neutron will provide internal dns resolution/"dns-proxy" over dhcp agent (dnsmasq) | 14:12 |
| daidv | we already impleted distributed DHCP aka flow-based dhcp | 14:13 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/1900934 for reference | 14:13 |
| daidv | My idea is having the same way to provide dns-proxy, then we can make internal dns resolution work like aws/gcp over 169.254.169.253/169.254.169.254 | 14:14 |
| daidv | based on ovs flow and an os-ken app work as dns-proxy | 14:14 |
| mlavalle | or similar to OVN, right? | 14:14 |
| daidv | 100% yes | 14:15 |
| daidv | ovn also check the north bound db | 14:15 |
| ralonsoh | that means only stored records in Neutron will be provided locally? | 14:16 |
| daidv | and then decide if it need to forward to real dns | 14:16 |
| daidv | ralonsoh: no, my idea is dns proxy only | 14:16 |
| lajoskatona | you mean external DNS service? | 14:16 |
| daidv | yeah, not really external DNS but internal cloud provider dns for both perpose | 14:17 |
| daidv | 1. resolve like ***.database.openstack.local to private IP | 14:17 |
| daidv | 2. even it can resolve public domain depend on real DNS server which is deployed by cloud owner | 14:18 |
| daidv | The case study from my side is i want to resolve the domain of database service without dhcp agent, without ovn | 14:18 |
| daidv | But we can do more than that, for any cloud service which is need domain and failover | 14:19 |
| daidv | in case of database service, when we failover the database instance, the ip is changed, so dns is a common solution to dealing with it | 14:19 |
| daidv | to make in-VPC instance connect do database on that VPC | 14:20 |
| daidv | VPC=VXLAN | 14:20 |
| lajoskatona | thanks, as I see this can be useful not only for db instances but for a wider audience | 14:22 |
| daidv | sure, for example, vpn cluster high available based on dns | 14:23 |
| ralonsoh | how do we store the DNS records in Neutron? | 14:24 |
| ralonsoh | I'm trying to find it | 14:24 |
| daidv | Now, neutron have plugin to trigger creating new dns record on Designate | 14:24 |
| daidv | but that's different work | 14:25 |
| daidv | 1. We are not normally need create dns record for each VM | 14:25 |
| daidv | 2. after Designate store dns record to DB, it will sync with miniDNS <-> PowerDNS/Bind9 | 14:26 |
| daidv | So, we still need a way to connect to our PowerDNS/Bind9 over dnsmasq inside DHCP Agent/over OVN | 14:26 |
| daidv | or we need provide VLAN for VM and let network team do that | 14:27 |
| haleyb | that seems outside the scope of this rfe? | 14:28 |
| daidv | I think so | 14:28 |
| ralonsoh | ok, I think that could be a discussion for the spec, I would like to know what new information will be needed to be passed, via RPC or whatever, to the OVS agent | 14:29 |
| daidv | we dont care about how to create dns record, it can be created by neutron-designate or create by CMP-outside openstack | 14:29 |
| mlavalle | ralonsoh: ++ | 14:29 |
| daidv | ah oki, we need to provide DNS Server IP for OVS Agent via configuration | 14:30 |
| daidv | and we can will a ovs flow (automatically for everytime restart ovs agent) to capture packet go to 169.254.169.253:53 | 14:30 |
| daidv | and then sent it to CONTROLLER:0 | 14:31 |
| lajoskatona | can't that flow be installed by the agent extension? | 14:31 |
| daidv | inside controller, we make a os-ken app like dhcp app now, but it will work like a dns proxy | 14:31 |
| lajoskatona | I think I asked that in the wip review as well | 14:32 |
| daidv | lajoskatona: sure, we can, when extension is enabled --> we restart ovs agent --> flow will be installed | 14:32 |
| lajoskatona | but perhaps ralonsoh is right about spec to see this and have space for questions | 14:32 |
| daidv | https://specs.openstack.org/openstack/neutron-specs/specs/wallaby/distributed_dhcp.html | 14:33 |
| daidv | The solution is similar with this spec | 14:33 |
| slaweq | so you simply pass all dns requests to the u/s dns servers which are '2606:4700:4700::1111', '1.1.1.1' in your PoC? Do I get it right? | 14:34 |
| lajoskatona | yes, that's good that we already have similar example | 14:34 |
| ralonsoh | I have the same question as slaweq, that doesn't match with your previous comments | 14:34 |
| daidv | slaweq: only packet match 169.254.169.253:53 and dns servers can be internal | 14:34 |
| daidv | It depend on the design of each system | 14:35 |
| slaweq | but how you will resolve internal names like for e.g. those db servers which you've mentioned earlier? | 14:35 |
| slaweq | with dhcp agent we have dnsmasq which knows that such hostname (vm name) is associated with this IP address and replies to such requests IIRC | 14:36 |
| daidv | my internal DNS server hold that dns records | 14:36 |
| daidv | dns records is created by designate or my own cmp | 14:36 |
| daidv | imagine, I use trove, so Trove generate dns record in Designate | 14:37 |
| slaweq | ok, so it is not like in e.g. ovn so that neutron-ovs-agent will have this knowledge, but it will behave only as proxy to pass dns requests to some external dns server (configured by you) | 14:37 |
| slaweq | correct? | 14:37 |
| daidv | correct | 14:38 |
| ralonsoh | then why don't set this DNS server in the DHCP information? | 14:38 |
| slaweq | so what's the point of having all of this, can't you just configure your dns server in the vm? | 14:38 |
| ralonsoh | ^^ same comment | 14:38 |
| slaweq | ralonsoh exactly, you were faster asking this :) | 14:38 |
| daidv | how can you make VM inside VXLAN network without external network | 14:39 |
| daidv | connect to DNS Server? | 14:39 |
| daidv | so we can make it possible | 14:39 |
| ralonsoh | ok, now I understand | 14:39 |
| ralonsoh | so only the compute node needs to have access to this DNS server | 14:40 |
| slaweq | yeah, makes sense if it is for the isolated networks | 14:40 |
| slaweq | I missed that piece too | 14:40 |
| daidv | of course, we will config 169.254.169.253 in Subnet DHCP | 14:40 |
| daidv | Subnet DNS | 14:40 |
| daidv | ralonsoh: that, only compute | 14:40 |
| slaweq | now it makes sense for me, thx for explanation | 14:40 |
| ralonsoh | then OK for me, that extension makes sense, I think I'm ready to vote | 14:41 |
| mlavalle | will we still have a spec? | 14:41 |
| ralonsoh | yes for sure | 14:41 |
| haleyb | i would like to see a spec as well | 14:41 |
| mlavalle | in that case I'm ready to vote, then | 14:42 |
| haleyb | we can vote, then daidv can you work on a spec and we can discuss more details there? | 14:42 |
| ralonsoh | +1 (plus a spec) | 14:42 |
| mlavalle | +1 with a spec | 14:42 |
| haleyb | +1 | 14:42 |
| lajoskatona | +1 | 14:42 |
| slaweq | +1 from me | 14:42 |
| slaweq | just remember about updating our docs too :) | 14:43 |
| haleyb | ack. i'll mark it approved and add a note | 14:43 |
| haleyb | thanks daidv for presenting! | 14:43 |
| daidv | thank you all | 14:43 |
| daidv | I will make a spec, and comment to the RFE | 14:44 |
| haleyb | jimin3shin[m]: ok, thanks for waiting, i think we have time to discuss your rfe | 14:44 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2107316 | 14:44 |
| haleyb | and i'll admit i missed your response in the bug about attending today | 14:45 |
| jimin3shin[m] | oh I didn't notice that I have to put this in the on demand agenda | 14:46 |
| jimin3shin[m] | do I have to describe about the rfe? | 14:47 |
| haleyb | jimin3shin[m]: np, it's maybe not obvious | 14:47 |
| mlavalle | that's ok, let's move on, we are running out of time | 14:47 |
| jimin3shin[m] | I suggest add more information to the network-ip-availabilites response, to calculate the number of available ips "in the whole network", and the number of available ips "in the allocation pools". | 14:49 |
| jimin3shin[m] | Current api response doesn't have enough information to calculate them. | 14:49 |
| jimin3shin[m] | This is spec for the change. | 14:50 |
| jimin3shin[m] | https://review.opendev.org/c/openstack/neutron-specs/+/947826 | 14:50 |
| lajoskatona | thanks for spec | 14:50 |
| ralonsoh | so basically you are adding used_ips_in_allocation_pool and allocation_pool_ips | 14:52 |
| ralonsoh | right? | 14:52 |
| ralonsoh | (and changing used_ips with used_ips_in_total) | 14:53 |
| daidv | This look like a "summary" information instead of port list by specific subnet | 14:54 |
| ralonsoh | hello? | 14:54 |
| haleyb | so my first question is can we just add more info in the GET without adding an extension? | 14:54 |
| ralonsoh | if we change the API that will require an extension | 14:54 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/2025.1: Consider logging options when using OVNdbsync https://review.opendev.org/c/openstack/neutron/+/952583 | 14:54 |
| ralonsoh | but we can add fields only, instead of changing the current ones | 14:54 |
| ralonsoh | this is always easiest | 14:55 |
| jimin3shin[m] | oh I see | 14:55 |
| jimin3shin[m] | then I think it's better to add more fields instead of changing them, because in the spec I was changing the value of the total_ips | 14:55 |
| haleyb | from reading the older bug https://bugs.launchpad.net/neutron/+bug/1843211 it was hard to see what the plan was | 14:55 |
| jimin3shin[m] | in the current api response, total_ips is different depending on if the network have allocation pools | 14:56 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/2025.1: Consider logging options when using OVNdbsync https://review.opendev.org/c/openstack/neutron/+/952583 | 14:57 |
| jimin3shin[m] | so I suggested to change total_ips to "total_ips and allocation_pool_ips" | 14:57 |
| jimin3shin[m] | but I think it's better to keep total_ips, and add two more fields for "total_ips and allocation_pool_ips" in the spec | 14:58 |
| haleyb | and totals for used ips correct? | 14:58 |
| slaweq | there is one thing to remember regarding allocation_pools - IIRC even if allocation_pool(s) are defined, admin can still allocate manually IP address from outside of the allocation pool for the port. It is only for the automated allocation for the regular users | 14:58 |
| jimin3shin[m] | yes | 14:58 |
| slaweq | so I think that proposed change has a lot of sense | 14:58 |
| ralonsoh | agree, is just a matter of knowing what means each parameter exactly | 14:59 |
| slaweq | total_ips, total_available_ips and then available_allocation_pool_ips makes sense IMO | 14:59 |
| ralonsoh | the documentation in the Neutron API must be sharp | 14:59 |
| slaweq | ralonsoh ++ | 14:59 |
| lajoskatona | +1 | 15:00 |
| mlavalle | +1 | 15:00 |
| haleyb | yes, if we are updating this let's make sure it's clear | 15:00 |
| ralonsoh | in any case, as slaweq mentioned, this is good | 15:00 |
| ralonsoh | so +1 for it | 15:00 |
| haleyb | +1 | 15:00 |
| lajoskatona | +1 from me also for the idea and RFE | 15:00 |
| slaweq | +1 | 15:00 |
| haleyb | jimin3shin[m]: ok, i'll approve it, we can continue review in the spec you already proposed | 15:01 |
| haleyb | #link https://review.opendev.org/c/openstack/neutron-specs/+/947826 | 15:01 |
| haleyb | ok, we are at time, thanks for attending everyone, have a good weekend! | 15:01 |
| haleyb | #endmeeting | 15:01 |
| opendevmeet | Meeting ended Fri Jun 13 15:01:56 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-06-13-14.00.html | 15:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-06-13-14.00.txt | 15:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-06-13-14.00.log.html | 15:01 |
| jimin3shin[m] | thank you, and i'll also make change the spec | 15:01 |
| mlavalle | \o | 15:02 |
| ralonsoh | have a nice weekend! | 15:02 |
| daidv | bye | 15:02 |
| lajoskatona | o/ | 15:02 |
| jimin3shin[m] | have a nice weekend! | 15:02 |
| slaweq | o/ | 15:03 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/2024.2: Consider logging options when using OVNdbsync https://review.opendev.org/c/openstack/neutron/+/952586 | 15:15 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/2024.2: Consider logging options when using OVNdbsync https://review.opendev.org/c/openstack/neutron/+/952586 | 15:15 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [eventlet-removal] Remove the usage of eventlet in the MacVTAP agent https://review.opendev.org/c/openstack/neutron/+/952219 | 15:27 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2025.1: Add state reporting back to metadata agents https://review.opendev.org/c/openstack/neutron/+/952561 | 15:34 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Make ``tunnel_ranges`` and ``network_vlan_ranges`` private members https://review.opendev.org/c/openstack/neutron/+/948313 | 15:35 |
| ralonsoh | haleyb, hello! If you have 1 min: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/948314 | 15:35 |
| ralonsoh | thanks! | 15:35 |
| ralonsoh | I'm leaving now, have a nice weekend | 15:35 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Add network_data validation for trunks https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/941355 | 16:01 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/2025.1: Prepare to handle ha_chassis_group for LRP https://review.opendev.org/c/openstack/ovn-octavia-provider/+/948314 | 16:51 |
| opendevreview | Merged openstack/neutron stable/2024.2: [FT] Improve ``test_assert_pings_during_br_phys_setup_not_lost*`` tests https://review.opendev.org/c/openstack/neutron/+/952552 | 17:48 |
| opendevreview | Merged openstack/neutron stable/2024.1: [FT] Improve ``test_assert_pings_during_br_phys_setup_not_lost*`` tests https://review.opendev.org/c/openstack/neutron/+/952553 | 17:48 |
| opendevreview | Brian Haley proposed openstack/neutron stable/2025.1: Add state reporting back to metadata agents https://review.opendev.org/c/openstack/neutron/+/952561 | 18:23 |
| opendevreview | Merged openstack/neutron stable/2025.1: Allow empty gateway IP in subnets from subnet pools https://review.opendev.org/c/openstack/neutron/+/952562 | 18:43 |
| opendevreview | Merged openstack/neutron stable/2024.2: Allow empty gateway IP in subnets from subnet pools https://review.opendev.org/c/openstack/neutron/+/952564 | 18:43 |
| opendevreview | Merged openstack/neutron stable/2024.1: Allow empty gateway IP in subnets from subnet pools https://review.opendev.org/c/openstack/neutron/+/952565 | 18:43 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron stable/2024.2: Consider logging options when using OVNdbsync https://review.opendev.org/c/openstack/neutron/+/952586 | 19:28 |
| opendevreview | Merged openstack/neutron master: Reduce metadata port lookup log message to warning https://review.opendev.org/c/openstack/neutron/+/951870 | 23:13 |
| opendevreview | Merged openstack/neutron master: Add state reporting back to metadata agents https://review.opendev.org/c/openstack/neutron/+/952399 | 23:38 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!