| opendevreview | Harald Jensås proposed openstack/neutron master: Add v6 Option 59 to SUPPORTED_DHCP_OPTS_MAPPING https://review.opendev.org/c/openstack/neutron/+/962317 | 00:53 |
|---|---|---|
| *** dsan_ is now known as dsan | 01:47 | |
| *** liuxie is now known as liushy | 05:58 | |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 06:16 |
| opendevreview | yatin proposed openstack/neutron-tempest-plugin master: Remove 2025.2 (Flamingo) ubuntu jobs https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/962322 | 08:04 |
| opendevreview | Théo Van Gyzel proposed openstack/neutron master: Fixed: network object was not updated after calling the enable driver while configure DHCP for a network https://review.opendev.org/c/openstack/neutron/+/962323 | 08:14 |
| opendevreview | Théo Van Gyzel proposed openstack/neutron master: Fix network not up to date after DHCP enable driver called https://review.opendev.org/c/openstack/neutron/+/962323 | 08:24 |
| opendevreview | Eduardo Olivares proposed openstack/neutron master: WIP: new job tempest-multinode-with-bgp https://review.opendev.org/c/openstack/neutron/+/962188 | 12:34 |
| opendevreview | Arnaud Morin proposed openstack/neutron master: Allow restoration of tun_ofports on agent restart https://review.opendev.org/c/openstack/neutron/+/860270 | 13:06 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: WIP: bgp: Add agent events that update chassis https://review.opendev.org/c/openstack/neutron/+/961854 | 13:13 |
| *** sfernand_ is now known as sfernand | 13:28 | |
| haleyb | i'll start meeting in a second | 14:00 |
| haleyb | #startmeeting neutron_drivers | 14:02 |
| opendevmeet | Meeting started Fri Sep 26 14:02:21 2025 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:02 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:02 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:02 |
| haleyb | sorry was in other meeting | 14:02 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh | 14:02 |
| mlavalle | \o | 14:02 |
| ralonsoh | hello | 14:02 |
| ralonsoh | slaweq, cannot attend today | 14:02 |
| mtomaska | o/ | 14:02 |
| lajoskatona | o/ | 14:02 |
| haleyb | ralonsoh: thanks, i think we'd still have quorum with the rest of us | 14:03 |
| haleyb | we did have a couple of topics, not sure if Dejan is here | 14:04 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2123836 | 14:04 |
| haleyb | [RFE] Set a local TXT record in the DHCP agent/dnsmasq | 14:04 |
| haleyb | #link https://review.opendev.org/c/openstack/neutron/+/950486 is the proposed patch | 14:06 |
| haleyb | dsan: are you here? | 14:06 |
| dsan | yep | 14:07 |
| haleyb | ah, can you talke a little about your RFE? | 14:07 |
| dsan | yeah sure | 14:07 |
| dsan | i tried to explain it a bit on launchpad | 14:07 |
| dsan | with use the ability to have a local txt record in dnsmasq | 14:08 |
| dsan | as kind of a side effect which allows to monitor it | 14:08 |
| dsan | we thought it might me usefull to others | 14:09 |
| dsan | so a good candidate to upstream | 14:09 |
| ralonsoh | Who is monitoring this process? How does it works? | 14:09 |
| dsan | it's at the infra level, we wish to ensure that dhcp is really available | 14:11 |
| ralonsoh | so what process is monitoring the dnsmasq process? | 14:11 |
| ralonsoh | outside openstack, I guess | 14:11 |
| dsan | i think it's blackbox exporter running the actual dns queries | 14:12 |
| mlavalle | I think he means out side OpenStack | 14:12 |
| mlavalle | and that leaves options open for other potential adopters | 14:12 |
| mlavalle | right? | 14:13 |
| haleyb | so is it going into each network namespace and running a command? | 14:13 |
| ralonsoh | dsan, are you still there? | 14:14 |
| dsan | yep | 14:14 |
| dsan | was checking what tool was doing the work | 14:15 |
| dsan | so its an internal tool that does the query | 14:15 |
| ralonsoh | why is that needed? The DHCP agent is in charge of this process | 14:16 |
| ralonsoh | dnsmasq is a child process of the DHCP agent | 14:16 |
| ralonsoh | that is launched with a wrapper | 14:16 |
| ralonsoh | if the child process fails and dies, the DHCP agent will respawn it | 14:17 |
| haleyb | it just doesn't do periodic queries to see if it's able to respond | 14:17 |
| ralonsoh | ok, I still have very little information about this | 14:19 |
| ralonsoh | for example, how to make this check, things like this | 14:20 |
| ralonsoh | dsan, how the check is done? | 14:20 |
| dsan | with a custom go tool | 14:20 |
| dsan | that happens to also do the dns queries in each namespace | 14:21 |
| ralonsoh | yeah, and do you need this txt field for that? | 14:21 |
| ralonsoh | I mean, you can use "dig" against the dnsmasq process to check its liveness | 14:21 |
| ralonsoh | why is this field needed? | 14:21 |
| lajoskatona | some reference for usage in random docs, i.e.: https://www.ibm.com/docs/en/i/7.4.0?topic=td-problem-dns-records-are-not-being-updated-by-dhcp | 14:22 |
| dsan | is when dnsmasq_local_resolv is that to true | 14:24 |
| dsan | that part was on launchpad | 14:24 |
| dsan | https://bugs.launchpad.net/neutron/+bug/2123836 | 14:24 |
| lajoskatona | ok, so if the monitor can't have the txt record from dnsmasq in the namespace you know that the clients in the VMs also has issues so the dnsmasq process is failing and have to do something on the network node? | 14:27 |
| dsan | yes | 14:28 |
| dsan | we know, there's some kind of issue in dnsmasq/the DHCP agent/the underlying network/etc. | 14:29 |
| lajoskatona | ok thanks | 14:29 |
| ralonsoh | ok, I'm not going to insist more on this because it is difficult obtain information from you. I would like to have a description of what is the process you implemented to use this txt record, how are you doing that | 14:29 |
| ralonsoh | please, add this in the launchpad | 14:29 |
| haleyb | to let others take advantage of this option, it seems to me like it should be in the dhcp-agent, then it can respawn and log a warning? | 14:30 |
| dsan | ok, i'll gather more details | 14:30 |
| haleyb | ok thanks dsan | 14:31 |
| dsan | there's also the HA part/underlying network aspect | 14:31 |
| dsan | it's one thing that the DHCP agent ensures that dnsmasq is running | 14:31 |
| dsan | and another that the environment is also OK | 14:32 |
| haleyb | understood | 14:32 |
| dsan | anyway thanks for your time | 14:32 |
| haleyb | we had one more item | 14:32 |
| haleyb | i had forgotten to add to agenda | 14:32 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2124215 | 14:32 |
| haleyb | [RFE] Implement more graceful handling of dhcp_lease_duration reduction | 14:32 |
| haleyb | jcmoore: are you here? | 14:33 |
| jcmoore | Yes, I'm here | 14:33 |
| haleyb | i think i understand the ask, can you just give a quick overview, don't know if others have read it all | 14:34 |
| ralonsoh | yes and is a legit bug, IMO | 14:34 |
| haleyb | and i think we can work around it based on the comments | 14:35 |
| jcmoore | Sure. In the event that the dhcp lease time is reduced by an amount greater than half of the previous lease duration, the lease will expire before the client has an opportunity to renew | 14:35 |
| jcmoore | For Windows clients, this means that the next time the client tries to renew, dnsmasq will have expired the lease, therefore there will be no active lease to renew | 14:36 |
| ralonsoh | ^^ what happen at this point? | 14:36 |
| jcmoore | As a result, dnsmasq will issue a NAK and that will cause Windows to completely release the IP (dropping all active connections) and perform a new DORA cycle | 14:37 |
| ralonsoh | hmmm that's bad, for sure | 14:37 |
| jcmoore | Linux is much more forgiving, it retains the IP while it's working to perform the DORA | 14:38 |
| haleyb | so based on the comments, it seems ok to have the lease as infinite in the file to avoid the NAK, since we only have leases for known ports anyway. | 14:38 |
| ralonsoh | I'm trying to figure out what could be the problem with this | 14:39 |
| haleyb | we continue to advertise the lease interval in responses based on the config value | 14:39 |
| jcmoore | That's my take, given the very specific way that Neutron is driving/using dnsmasq | 14:39 |
| ralonsoh | what if the subnet DHCP range is reduced? | 14:39 |
| ralonsoh | you'll leave a lease in the file | 14:40 |
| ralonsoh | my concern here is that we introduce, by accident, a regression with this infinite timeout | 14:41 |
| ralonsoh | that we could introduce* | 14:42 |
| haleyb | ralonsoh: so a port changes from being in the allocation range to out? | 14:42 |
| ralonsoh | no | 14:42 |
| haleyb | ralonsoh: so the lease duration is reduced? | 14:44 |
| ralonsoh | no, it isn't | 14:44 |
| ralonsoh | the port IP assignation is not changed | 14:44 |
| haleyb | i guess i don't understand your question "what if the subnet DHCP range is reduced?" | 14:45 |
| ralonsoh | I'm just thinking in any situation that could leave a record indefinitely in the leases file | 14:45 |
| ralonsoh | because of this change | 14:45 |
| ralonsoh | in any case, this file belongs to the dnsmasq process that is a child process of the DHCP agent | 14:46 |
| ralonsoh | so it should be handled by the DHCP agent | 14:47 |
| jcmoore | I think _release_unused_leases() should clean up any leases for ports which are no longer valid, right? | 14:47 |
| ralonsoh | yes | 14:47 |
| jcmoore | So if we init the leases file with infinte leases for only valid ports, dnsmasq will take care of updating the lease timeout upon the next renewal by a client. If a client never renews but the port is valid, it will remain in the leases file with an infinite lease. | 14:49 |
| jcmoore | Is that a "don't care" caes? | 14:49 |
| haleyb | we'd have to add tests for any corner cases, but i think the check to match the entries might be easier not having the lease time there perhaps? | 14:49 |
| ralonsoh | right, we need to add proper testing for possible corner cases | 14:51 |
| ralonsoh | in any case, as commented, this is a legit bug | 14:51 |
| jcmoore | That works but there's an edge case with that also in the event there is no existing leases file upon startup | 14:51 |
| jcmoore | If the duration has been reduced and there is no existing leases file to parse, then we'd default to the existing behavior of using the current lease duration to init the leases file | 14:52 |
| jcmoore | Likely an even smaller proability of hitting this but not unlikely | 14:52 |
| jcmoore | Using an infinite lease seems like it would solve both of these issues, without the additional work of parsing/retaining existing leases, if existing leases are present | 14:54 |
| haleyb | right, and i think the number of entries in all these dnsmasq files is the same as before since it should only be existing ports that are there | 14:56 |
| mlavalle | jcmoore, would you implement it? | 14:56 |
| jcmoore | Correct. They would just start out with 0 instead of the currently configured lease duration | 14:56 |
| jcmoore | Sure, if we want to init to 0, that's easy enough to implement. | 14:57 |
| haleyb | it's more about testing we don't break things | 14:58 |
| lajoskatona | +1 | 14:58 |
| haleyb | should we vote? | 14:58 |
| ralonsoh | +1 | 14:58 |
| lajoskatona | +1 | 14:58 |
| mlavalle | +1 | 14:58 |
| haleyb | i'm +1, and don't think we need a spec as it's really a bug | 14:58 |
| ralonsoh | agree | 14:59 |
| haleyb | jcmoore: can you just put any info from above regarding possible test cases in the bug? so we don't forget them? | 14:59 |
| jcmoore | Yes, I'll be sure to capture as many edge cases as we can currently foresee | 15:00 |
| haleyb | and thanks for finding the issue and working on it, reach out if you have questions on submitting patches | 15:00 |
| haleyb | i'll mark approved | 15:00 |
| haleyb | thanks for attending everyone, have other meeting to run to | 15:01 |
| haleyb | and have a good weekend | 15:01 |
| haleyb | #endmeeting | 15:01 |
| opendevmeet | Meeting ended Fri Sep 26 15:01:14 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-09-26-14.02.html | 15:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-09-26-14.02.txt | 15:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-09-26-14.02.log.html | 15:01 |
| mlavalle | \o | 15:01 |
| lajoskatona | Bye! | 15:01 |
| ralonsoh | bye | 15:01 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Introduce Main router and chassis router commands https://review.opendev.org/c/openstack/neutron/+/959890 | 15:21 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Introduce BGP chassis commands https://review.opendev.org/c/openstack/neutron/+/960422 | 15:25 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [eventlet-removal] Don't use eventlet in the unit/functional tests https://review.opendev.org/c/openstack/neutron/+/952258 | 19:46 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Simplify the logic to create a "HA_Chassis_Group" https://review.opendev.org/c/openstack/neutron/+/962402 | 20:26 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == [OVN] The external networks GW chassis must the same as the GW LRP https://review.opendev.org/c/openstack/neutron/+/962155 | 20:27 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == [OVN] The external ports HA_Chassis_Group belongs to the network https://review.opendev.org/c/openstack/neutron/+/962403 | 20:27 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Always exclude the local chassis creating ``HA_Chassis_Group`` https://review.opendev.org/c/openstack/neutron/+/962191 | 20:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Simplify the logic to create a "HA_Chassis_Group" https://review.opendev.org/c/openstack/neutron/+/962402 | 20:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Remove maintenance method "check_for_ha_chassis_group" https://review.opendev.org/c/openstack/neutron/+/962404 | 20:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Remove check fot external ports support https://review.opendev.org/c/openstack/neutron/+/962406 | 21:17 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == [OVN] The external ports HA_Chassis_Group belongs to the network https://review.opendev.org/c/openstack/neutron/+/962403 | 21:18 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == [OVN] The external networks GW chassis must the same as the GW LRP https://review.opendev.org/c/openstack/neutron/+/962155 | 21:18 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Introduce service plugin https://review.opendev.org/c/openstack/neutron/+/958100 | 22:52 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Introduce Main router and chassis router commands https://review.opendev.org/c/openstack/neutron/+/959890 | 22:52 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Introduce BGP chassis commands https://review.opendev.org/c/openstack/neutron/+/960422 | 22:52 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: OVN agent BGP extension https://review.opendev.org/c/openstack/neutron/+/960895 | 22:52 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: bgp: Add openflow configuration for BGP bridges https://review.opendev.org/c/openstack/neutron/+/961293 | 22:52 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!