| opendevreview | Takashi Kajinami proposed openstack/os-vif master: Clean up Windows support https://review.opendev.org/c/openstack/os-vif/+/932436 | 00:56 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/os-vif master: Drop kuryr-kubernetes job https://review.opendev.org/c/openstack/os-vif/+/932474 | 02:17 |
| opendevreview | Liushy proposed openstack/neutron master: Only consider the IPv4 subnets when creating a FIP https://review.opendev.org/c/openstack/neutron/+/932405 | 03:56 |
| gsamfira | ralonsoh skrobul: I am ready whenever you folks are. | 06:01 |
| ralonsoh | gsamfira, hello | 06:08 |
| ralonsoh | can you post the LP bug id? | 06:08 |
| gsamfira | yup. One sec | 06:08 |
| ralonsoh | https://bugs.launchpad.net/neutron/+bug/1995078 | 06:08 |
| ralonsoh | found it | 06:08 |
| gsamfira | there's also this one: https://bugs.launchpad.net/neutron/+bug/2084536 | 06:09 |
| gsamfira | you mentioned last time we should have one that states we need to use internal VLAN networks connected to virtual routers | 06:09 |
| gsamfira | as a use case | 06:09 |
| ralonsoh | the second is a bit different | 06:10 |
| ralonsoh | in the second the network that is connected to the baremetal node is the internal | 06:10 |
| ralonsoh | in what are you interested? | 06:10 |
| gsamfira | Yes. But it will probably help the first one as well. | 06:11 |
| gsamfira | That bug is how I ended up opening the second | 06:11 |
| ralonsoh | no, the second is for routed traffic | 06:11 |
| ralonsoh | if you use the same scheduler for GW ports and extenal ports, that is using HA_Chassis_Group, the problem is solved | 06:12 |
| gsamfira | hmm | 06:12 |
| gsamfira | even if we connect multiple VLAN networks to a router that has an external port set? | 06:12 |
| ralonsoh | that is different | 06:12 |
| gsamfira | ahh, right | 06:13 |
| ralonsoh | in the 1st LP, the VLAN network is the GW network | 06:13 |
| gsamfira | correct | 06:13 |
| gsamfira | they are indeed different | 06:13 |
| gsamfira | I am willing to work on the first one as well as the second one. But we need to make sure that the second one is something that is acceptable to have in neutron | 06:14 |
| gsamfira | I can detail our user story if it helps | 06:14 |
| ralonsoh | the problem in LP#2084536 is that 1) I don't know how OVN will react to binding an internal interface (I need to ask this to core OVN folks) and 2) if you bind the internal interface to a node, the GW port must be too in this node | 06:15 |
| ralonsoh | because, if I'm not wrong, what you need is to route baremetal nodes traffic | 06:15 |
| gsamfira | yes | 06:15 |
| gsamfira | we did this in our lab | 06:16 |
| ralonsoh | if you send the traffic of the baremetal nodes to a node and then you snat this traffic in other, then you won't have any benefit | 06:16 |
| ralonsoh | the snat should be done in the same GW chassis too | 06:16 |
| ralonsoh | but my first issue, and I need to ask this first, is what is the effect of binding an internal interface | 06:17 |
| gsamfira | as far as I can tell, there is no SNAT. It's just L3 routing. The difference when binding the internal router port to the same HA chassis group as the network is that for external ports at least, traffic will go through the chassis where the port i bound | 06:17 |
| gsamfira | for VMs, the distributed router port feature still works | 06:17 |
| gsamfira | if we have an external port attached to the router, the traffic from the internal VLAN network is redirected from the chassis where the internal port is bound, to the chassis where the extenal port is bound | 06:18 |
| gsamfira | and then NAT takes place | 06:18 |
| gsamfira | and this happens when you need to communicate with a network not directly connected to the router | 06:18 |
| gsamfira | basically the router sending the traffic to its default GW | 06:19 |
| gsamfira | this essentially mimics how neutron-gateway works | 06:19 |
| gsamfira | via the veth pairs and the qrouter netns | 06:19 |
| gsamfira | If you'd like, I can share my screen and walk through the setup | 06:20 |
| gsamfira | if you're willing to join a call | 06:20 |
| ralonsoh | not necessary, it is better if you share this info in the LP bug | 06:20 |
| gsamfira | sure! | 06:20 |
| ralonsoh | my question is about the VLAN traffic | 06:20 |
| ralonsoh | if we have other VMs in this VLAN network | 06:20 |
| ralonsoh | I don't know if the traffic for these VMs must got to the chassis with the internal interface bound | 06:21 |
| ralonsoh | instead of being redirect directly to the chassis with the other VM in the geneve network | 06:21 |
| gsamfira | I can do a packet capture on the compute nodes and confirm whether the distributed port feature works. IE: the vrouter MAC is replaced with the local bridge MAC and put on the wire | 06:21 |
| gsamfira | without redirecting to the gw chassis | 06:22 |
| ralonsoh | in your LP bug, there should not be GW | 06:22 |
| ralonsoh | only two internal networks | 06:22 |
| ralonsoh | right? | 06:23 |
| gsamfira | Yes, but attaching a GW also needs to work. And it does | 06:23 |
| gsamfira | I will spend today on doing some ovn-trace | 06:23 |
| gsamfira | and packet captures | 06:23 |
| gsamfira | will include everything in the LP bug | 06:23 |
| ralonsoh | in the case of having a GW network, the GW port must be located in the same chassis | 06:24 |
| ralonsoh | as the VLAN internal interface | 06:24 |
| gsamfira | it seems it does not need to be for things to work. The GW chassis can be on one set of GW chassis/HA chassis group, while the internal VLAN port can be on another | 06:24 |
| gsamfira | if both are bound | 06:24 |
| ralonsoh | ok, I'll try to check this this week | 06:25 |
| gsamfira | and it kind of makes sense. Once they're bound, the chassis to which they're bound, will respond to ARP | 06:25 |
| gsamfira | and this being VLAN, it works as any normal L2 network | 06:25 |
| ralonsoh | I don't understand the last part, who replies to ARP? | 06:26 |
| ralonsoh | what IP? | 06:26 |
| ralonsoh | ah, this chassis in particular is capturing the ARPs and replying, ok | 06:27 |
| gsamfira | the internal router port IP. If we have 192.168.100.0/24, which we attach to a router, the router interface IP will probably be 192.168.100.1 | 06:27 |
| gsamfira | yup | 06:27 |
| gsamfira | if that interface is bound to chassis01.cloud | 06:27 |
| gsamfira | then chassis01.cloud will reply with the MAC address of the port | 06:27 |
| gsamfira | the internal router port | 06:28 |
| gsamfira | it's VLAN so this will go on the physnet to which the VLAN is mapped | 06:28 |
| gsamfira | and everything works | 06:28 |
| gsamfira | same thing happens in external networks. The upstream GW needs to communicate with the external port of the virtual router | 06:28 |
| gsamfira | the internal VLANs are no different when it comes to neutron | 06:28 |
| gsamfira | the only difference is that we have a BM node, not an upstream router | 06:29 |
| gsamfira | but conceptually they are the same | 06:29 |
| ralonsoh | ok, I don't have baremetal nodes but I don't need them. Actually my main concern are the other VMs traffic with the interface bound | 06:29 |
| gsamfira | the internal VLANs are no different when it comes to neutron --> the internal VLANs are no different when it comes to ironic | 06:29 |
| gsamfira | fairn enough. I can do some packet capture, traces and dump flows to confirm nothing undesirable happens | 06:30 |
| ralonsoh | yeah, the main issue I want to check is the following scenario: | 06:30 |
| ralonsoh | you have the internal interface bound to chassis 1, a VLAN VM in chassis 2 and a geneve VM in chassis 3 | 06:31 |
| ralonsoh | if you route traffic form VLAN VM to geneve VM, this traffic must not go to chassis 1 | 06:31 |
| ralonsoh | that's my only concern (so far) | 06:32 |
| gsamfira | ack! | 06:32 |
| gsamfira | noted | 06:32 |
| gsamfira | as far as I can tell, it does, but I will do some sleuthing to confirm with flows, tcpdump, etc | 06:32 |
| gsamfira | and I will add it to the LP bug | 06:33 |
| gsamfira | it's in our best interest to get this to work. This cloud will probably reach around 800 BM nodes by mid next year. OVN is desirable :D | 06:34 |
| gsamfira | thanks ralonsoh! | 06:35 |
| ralonsoh | yw | 06:35 |
| opendevreview | Merged openstack/neutron stable/2023.2: Revert "[OVN] Prevent Trunk creation/deletion with parent port bound" https://review.opendev.org/c/openstack/neutron/+/921607 | 07:41 |
| opendevreview | Merged openstack/neutron stable/2023.1: Revert "[OVN] Prevent Trunk creation/deletion with parent port bound" https://review.opendev.org/c/openstack/neutron/+/921608 | 07:41 |
| opendevreview | Liushy proposed openstack/neutron master: Only consider the IPv4 subnets when creating a FIP https://review.opendev.org/c/openstack/neutron/+/932405 | 08:39 |
| *** liuxie is now known as liushy | 08:41 | |
| liushy | hi folks, please feel free too review: https://review.opendev.org/c/openstack/neutron/+/932405 ^-^ | 09:57 |
| ralonsoh | liushy, you need some testing there. You have, in tests.unit.objects.test_subnet some tests on ``test_find_candidate_subnets`` | 10:07 |
| ralonsoh | you should improve them to consider this new scenario | 10:07 |
| liushy | ralonsoh, OK | 10:08 |
| opendevreview | Liushy proposed openstack/neutron master: Only consider the IPv4 subnets when creating a FIP https://review.opendev.org/c/openstack/neutron/+/932405 | 10:42 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/neutron master: [OVN] Do not supply gateway_port if it's not binded to chassis https://review.opendev.org/c/openstack/neutron/+/931495 | 11:43 |
| opendevreview | Liushy proposed openstack/neutron master: Only consider the IPv4 subnets when creating a FIP https://review.opendev.org/c/openstack/neutron/+/932405 | 12:01 |
| opendevreview | Merged openstack/neutron stable/2024.1: "security_group_rules" is not a SG selectable field https://review.opendev.org/c/openstack/neutron/+/932333 | 12:18 |
| opendevreview | Merged openstack/neutron stable/2024.2: "security_group_rules" is not a SG selectable field https://review.opendev.org/c/openstack/neutron/+/932331 | 12:59 |
| opendevreview | Merged openstack/os-vif master: Remove Python 3.8 support https://review.opendev.org/c/openstack/os-vif/+/931480 | 12:59 |
| opendevreview | Liushy proposed openstack/neutron master: Only consider the IPv4 subnets when creating a FIP https://review.opendev.org/c/openstack/neutron/+/932405 | 13:27 |
| ralonsoh | haleyb, hello! https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930743 is so bug (in testing terms) that it will never pass the CI | 14:26 |
| ralonsoh | I'm going to divide it in chunks (changing one job each one) in order to pass the CI | 14:27 |
| ralonsoh | that's a shame for us to have an unstable CI... | 14:27 |
| haleyb | ralonsoh: ack, we definitely see some issues there | 14:38 |
| haleyb | with the -em of antelope can maybe remove the 2023.1 jobs from there, not that i think they failed | 14:38 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: [WSGI] Move all OVN jobs to use WSGI API module (1) https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/932520 | 15:01 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: [WSGI] Move all OVN jobs to use WSGI API module (2) https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/932524 | 15:07 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Stop running 2023.1 (Antelope) jobs in check/gate https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/932527 | 15:19 |
| opendevreview | Brian Haley proposed openstack/neutron-tempest-plugin master: Fix trunk transition waiting message https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/932549 | 18:36 |
| msaravan | Hi Network Gurus !! This is Saravanan from NetApp. I have a query on latest devstack's ovn configurations. I find the ping to floating IP works from the same host, and not from any external entity. I wanted to have a floating ip in the same network as where the devstack instance resides. | 19:26 |
| msaravan | The details of the command outputs and all other details are captured here : | 19:27 |
| msaravan | https://paste.opendev.org/show/b7EbXTrdf4HCH2GCfYKW/ | 19:27 |
| msaravan | Can you please help me fixing this issue. | 19:28 |
| msaravan | It used to work fine, when ovs is in place in old openstack releases. Now, we are on latest (Dalmatian), and as we are using ovn here, I am not sure what is missing, and why the connectivity from external network to the vm is not working. | 19:31 |
| haleyb | msaravan: it sounds to me like a network infrastructure issue, or a missing route on the source host? | 20:23 |
| haleyb | cardoe: you around? maybe we can pick an interlock time? | 20:24 |
| cardoe | Yep | 20:24 |
| cardoe | I think I saw we had some overlapping slots on Wednesday. | 20:24 |
| haleyb | i had booked tue/wed/thu/fri as placeholders, but sometime Wednesday would work | 20:26 |
| cardoe | So for me 1400 UTC or later is easiest. | 20:35 |
| cardoe | I got 1 other nod on that time from the channel if that sounds okay. | 20:38 |
| haleyb | 1400 UTC works | 20:43 |
| haleyb | cardoe: argh, actually there is an eventlet-removal discussion at 1400 so that won't work | 20:47 |
| haleyb | would have to be 1500 or later | 20:47 |
| cardoe | 1500 is fine | 20:47 |
| *** gmann is now known as gmann_afk | 20:58 | |
| *** gmann_afk is now known as gmann_ | 21:41 | |
| *** gmann_ is now known as gmann | 21:41 | |
| cardoe | maybe gmann will help me to get that setup correctly in the events | 21:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!