| opendevreview | Brian Haley proposed openstack/neutron master: Increase code coverage for floating_mangle_rules() https://review.opendev.org/c/openstack/neutron/+/914918 | 00:19 |
|---|---|---|
| opendevreview | Brian Haley proposed openstack/neutron-lib master: Fix incorrect links for the filtering spec https://review.opendev.org/c/openstack/neutron-lib/+/914826 | 01:19 |
| opendevreview | Ihtisham ul Haq proposed openstack/neutron master: Optimize deletion of static routes https://review.opendev.org/c/openstack/neutron/+/914900 | 06:46 |
| opendevreview | Ihtisham ul Haq proposed openstack/neutron master: Optimize deletion of static routes https://review.opendev.org/c/openstack/neutron/+/914900 | 08:02 |
| gaudenz | I would like to restore two old changes in gerrit originally submitted by others, but I don't have the permission to do so. Can someone restore them for me or should I just submit them with a new change ID? | 08:11 |
| gaudenz | This is about https://review.opendev.org/c/openstack/neutron/+/196393 and https://review.opendev.org/c/openstack/neutron/+/184474 | 08:11 |
| frickler | gaudenz: I think it will be useful to discuss the topic first, maybe at a team meeting or at the PTG next week | 09:12 |
| gaudenz | frickler: What's the best way to get this discussed? Should I add it to the PTG etherpad? | 09:36 |
| frickler | gaudenz: maybe wait for haleyb to chime in when they're around later | 10:22 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron unmaintained/xena: Remove tobiko job from the periodic queue https://review.opendev.org/c/openstack/neutron/+/914976 | 14:28 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron unmaintained/wallaby: Remove tobiko job from the periodic queue https://review.opendev.org/c/openstack/neutron/+/914977 | 14:31 |
| *** whoami-rajat_ is now known as whoami-rajat | 14:47 | |
| haleyb | gaudenz: those are really old changes and related to a really old bug, https://bugs.launchpad.net/neutron/+bug/1365438 - and there were concerns raised about the overhead of running conntrackd. | 15:09 |
| haleyb | can you describe the use case? | 15:09 |
| gaudenz | haleyb: The use case for conntrackd is basically HA failover of long lived TCP connections on a NAT router from an instance without a floating IP. This only works reliably if connection tracking states are synced to the standby router. | 15:24 |
| gaudenz | Depending on exact kernel tunables (eg. nf_conntrack_tcp_loose and nf_conntrack_tcp_be_liberal) it does not work at all otherwise or only works if the "inside" end of the connection sends a packet next. Packets from the outer side of the NAT will be rejected after a failover without connection tracking state synchronization. | 15:29 |
| haleyb | gaudenz: does https://review.opendev.org/c/openstack/neutron/+/618208 help at all? doing a big change like conntrackd would be something we'd need to discuss further and prioritize | 15:38 |
| *** gthiemon1e is now known as gthiemonge | 15:59 | |
| *** logan_ is now known as Guest4818 | 16:53 | |
| *** andreykurilin_ is now known as andreykurilin | 16:55 | |
| *** ganso_ is now known as ganso | 16:55 | |
| *** vishalmanchanda_ is now known as vishalmanchanda | 16:55 | |
| *** gmann_ is now known as gmann | 16:55 | |
| *** carloss_ is now known as carloss | 19:46 | |
| * haleyb wonders if he was disconnected all day or it's just very quiet | 19:55 | |
| gaudenz | haleyb: I think nf_conntrack_tcp_be_liberal can help in some cases. Not sure if it actually helps in the HA failover case. For conntrackd I'm willing on to work on this. I have an updated patch and fullstack test case ready for review. I don't think adding conntrackd will significantly increase the load on the hosts. Would be nice if we could discuss this at the PTG next week. | 21:05 |
| haleyb | gaudenz: ok, thanks for the follow-up. if you put it in the etherpad I can schedule it to one of our sessions | 21:06 |
| haleyb | https://etherpad.opendev.org/p/apr2024-ptg-neutron | 21:07 |
| greatgatsby_ | Hi. We've upgraded from yoga to zed in our kolla-ansible deployment. New VMs don't seem to be picking up an IP, and the only thing I've found so far is the new ports being created don't have `os-vif-delegation: true` while our older/existing VMs do. Not sure if this is the cause, or where to look for further troubleshooting. | 21:10 |
| haleyb | greatgatsby_: i don't think that flag would break anything, but I don't know much about it. you could try asking sean mooney in the nova channel since he would know more about the field | 21:24 |
| haleyb | are there any other things in the logs that might give a clue? dhcp or ovs agent logs? | 21:25 |
| haleyb | and i don't know much about kolla either :( | 21:25 |
| greatgatsby_ | haleyb: thanks. I did turn on debug logging and grepped for errors through all the logs when I spun up a VM, but nothing so far. Thanks for the nova channel suggestion. | 22:09 |
| *** dmitriis is now known as Guest15 | 22:38 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!