| opendevreview | OpenStack Proposal Bot proposed openstack/networking-bgpvpn master: Imported Translations from Zanata https://review.opendev.org/c/openstack/networking-bgpvpn/+/858008 | 02:50 |
|---|---|---|
| opendevreview | OpenStack Proposal Bot proposed openstack/neutron master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron/+/871935 | 03:53 |
| opendevreview | Ghanshyam proposed openstack/neutron-tempest-plugin master: Pin neutron-tempest-plugin for stable/wallaby jobs https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/871793 | 04:49 |
| opendevreview | Merged openstack/neutron master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron/+/871935 | 07:54 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Update tox.ini for tox4 https://review.opendev.org/c/openstack/ovsdbapp/+/871963 | 08:30 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Accept HA chassis group commands in HAChassisGroupAdd* https://review.opendev.org/c/openstack/ovsdbapp/+/871836 | 08:32 |
| slaweq | ralonsoh ykarel lajoskatona mlavalle hi, please check https://review.opendev.org/c/openstack/neutron/+/869554 when You will have few minutes | 08:34 |
| slaweq | thx in advance | 08:34 |
| ralonsoh | sure | 08:35 |
| ykarel | slaweq, ack | 08:44 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Update tox.ini for tox4 https://review.opendev.org/c/openstack/ovsdbapp/+/871963 | 08:44 |
| ralonsoh | folks ^^^ if you have 1 min | 08:44 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Accept HA chassis group commands in HAChassisGroupAdd* https://review.opendev.org/c/openstack/ovsdbapp/+/871836 | 08:45 |
| lajoskatona | slaweq, ralonsoh: ack | 08:48 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider master: Remove LB from LS belonging to provider networks https://review.opendev.org/c/openstack/ovn-octavia-provider/+/871263 | 09:04 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Accept HA chassis group commands in HAChassisGroupAdd* https://review.opendev.org/c/openstack/ovsdbapp/+/871836 | 09:28 |
| opendevreview | Merged openstack/neutron master: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871825 | 09:52 |
| opendevreview | Merged openstack/neutron master: [API] Add API extension and definition for default SG rules https://review.opendev.org/c/openstack/neutron/+/869554 | 10:47 |
| opendevreview | Merged openstack/neutron stable/zed: [Trunk] Update the trunk status with the parent status https://review.opendev.org/c/openstack/neutron/+/871760 | 10:47 |
| opendevreview | Merged openstack/neutron stable/yoga: [Trunk] Update the trunk status with the parent status https://review.opendev.org/c/openstack/neutron/+/871761 | 10:47 |
| opendevreview | Merged openstack/neutron stable/xena: [Trunk] Update the trunk status with the parent status https://review.opendev.org/c/openstack/neutron/+/871762 | 10:47 |
| sahid | o/ how do you feel about this one, looks like small and safe as it does not change conecpt of the query, but can improve significatly the performance for some usage of rbacs | 10:48 |
| sahid | https://review.opendev.org/c/openstack/neutron/+/871113 | 10:48 |
| opendevreview | Merged openstack/ovsdbapp master: Update tox.ini for tox4 https://review.opendev.org/c/openstack/ovsdbapp/+/871963 | 11:03 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Allow disable stateful security group extension on older OVN https://review.opendev.org/c/openstack/neutron/+/871982 | 11:05 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Deprecate allow_stateless_action_supported config option https://review.opendev.org/c/openstack/neutron/+/871983 | 11:05 |
| slaweq | ralonsoh ^^ those are the patches which we discussed today | 11:06 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Deprecate allow_stateless_action_supported config option https://review.opendev.org/c/openstack/neutron/+/871983 | 11:20 |
| opendevreview | yatin proposed openstack/neutron stable/zed: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871908 | 11:26 |
| opendevreview | yatin proposed openstack/neutron stable/yoga: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871909 | 11:26 |
| opendevreview | yatin proposed openstack/neutron stable/xena: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871990 | 11:27 |
| opendevreview | yatin proposed openstack/neutron stable/wallaby: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871991 | 11:27 |
| opendevreview | yatin proposed openstack/neutron stable/victoria: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871988 | 11:39 |
| opendevreview | yatin proposed openstack/neutron stable/ussuri: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871989 | 11:40 |
| *** labedz__ is now known as labed | 12:23 | |
| *** labed is now known as labedz | 12:23 | |
| labedz | hi guys, need some tip :) I am discovering the stormy waters of IPv6 + OVN + OpenStack and I am wondering how the hell upstream router knows where to 'route' tenant trafic to proper gateway? | 12:24 |
| labedz | in scenario of provider assigned IPv6 prefix for tenant (geneve) networks | 12:26 |
| ralonsoh | ping ykarel, mlavalle, mtomaska, slawek, obondarev, sahid, tobias-urdin, lajoskatona, amotoki | 13:59 |
| ralonsoh | the drivers meeting is in 1 min | 13:59 |
| ralonsoh | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Jan 27 14:00:27 2023 UTC and is due to finish in 60 minutes. The chair is ralonsoh. 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 |
| ralonsoh | hello all | 14:00 |
| lajoskatona | o/ | 14:00 |
| mlavalle | o/ | 14:00 |
| amotoki | hi | 14:00 |
| dmitriis | o/ | 14:00 |
| obondarev | hi | 14:00 |
| slaweq | hi | 14:01 |
| ykarel | o/ | 14:01 |
| ralonsoh | ok, I think we have quorum today | 14:01 |
| *** dasm|off is now known as dasm | 14:01 | |
| ralonsoh | we have one topic in the agenda | 14:02 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2002687 | 14:02 |
| ralonsoh | [RFE] Active-active L3 Gateway with Multihoming | 14:02 |
| ralonsoh | and dmitriis is here, so please, go on | 14:02 |
| sahid | o/ | 14:02 |
| dmitriis | The RFE follows the earlier effort to enable multiple gateway ports | 14:02 |
| dmitriis | but with some augmentations such as having multiple gateway ports on the same network | 14:03 |
| dmitriis | and enabling ECMP for default routes inferred from subnets automatically | 14:03 |
| dmitriis | there is an associated spec with more details outlined but I am happy to discuss some of them here | 14:03 |
| dmitriis | fnordahl and I are focusing on the OVN integration for now to keep the scope limited | 14:04 |
| lajoskatona | The spec: https://review.opendev.org/c/openstack/neutron-specs/+/870030 | 14:04 |
| ralonsoh | so the scope is limited to OVN only, right? | 14:04 |
| dmitriis | ralonsoh: yes, for now we are planning a mixin implementing the new API to be supported only with OVN | 14:04 |
| dmitriis | but I don't see red flags as far as using the L3 agent-based implementation | 14:05 |
| dmitriis | the spec has extensions not only for the API but also for router attributes | 14:06 |
| dmitriis | this is to control the ECMP behavior for default routes inferred from subnets | 14:06 |
| ralonsoh | is it needed any external agent? | 14:07 |
| fnordahl | no | 14:07 |
| dmitriis | we're using only the OVN functionality | 14:07 |
| dmitriis | when it comes to handling extra routes, OVN is smart enough to check whether next-hops have an overlap with the subnets directly reachable via a logical router port | 14:07 |
| slaweq | I didn't read whole spec yet, but can You do some short summary how this is different from the specs proposed some time ago by rubasov and other erricsson guys? | 14:07 |
| dmitriis | so if any extra routes are added, their next hops will have an overlap check and a reachability check done by OVN | 14:07 |
| slaweq | except that they wanted to implement it for ML2/OVS and L3 agent | 14:08 |
| dmitriis | slaweq: yes, 1 min | 14:08 |
| dmitriis | the diff is mainly in: 1. supporting multiple gws with the same network id | 14:08 |
| sahid | does this is only coupled to OVN or will it be possible to have this supported for OVS agent? | 14:08 |
| dmitriis | 2. automatically adding ECMP default routes | 14:08 |
| dmitriis | 3. extending the router with new attributes to specify the ECMP and BFD policy for the inferred default routes | 14:09 |
| mlavalle | sahid: for now, it is ovn focused | 14:09 |
| mlavalle | but in ricinple could be extended to ml2/ovs | 14:09 |
| dmitriis | mlavalle, sahid: yes | 14:10 |
| dmitriis | the BFD modelling in this spec is minimal | 14:10 |
| sahid | ok cool it's what i wanted to understand, sorry for the interuption | 14:10 |
| slaweq | dmitriis thx | 14:10 |
| ralonsoh | does it work with distributed FIPs? is there any clash? | 14:10 |
| mlavalle | good question I was about to ask | 14:10 |
| dmitriis | so, the spec is akin to implementing multiple snat-<router-uuid> namespaces in the l3 agent implementation terms | 14:12 |
| dmitriis | I'll try to explain a little more | 14:12 |
| fnordahl | distributed fip with OVN is currently implemented by exposing the instance mac directly on the external network, so traffic would go directly and not go through the router, so there should be no clash | 14:13 |
| slaweq | snat- namespaces? there is no something like that in ML2/OVN | 14:13 |
| dmitriis | slaweq: yes, I am just drawing an analogy | 14:13 |
| mlavalle | slaweq: he is using an analogy | 14:13 |
| slaweq | ah, ok | 14:14 |
| slaweq | sorry | 14:14 |
| dmitriis | yes, so, to fnordahl's point, there's a mechanism called 'external_mac' in OVN | 14:14 |
| dmitriis | which is relied on to implement distributed FIPs | 14:14 |
| dmitriis | and it doesn't collide with having multiple gateways | 14:15 |
| dmitriis | where we see some future imporovements is in avoiding asymmetric routing | 14:15 |
| dmitriis | which can be done by utilizing conntrack and the ecmp-symmetric-reply feature in OVN | 14:15 |
| dmitriis | this feature is not fully functional with distributed routing enabled | 14:16 |
| dmitriis | so that's where there would be some selective logic to implement from what I see | 14:16 |
| dmitriis | I noted that in the spec too | 14:17 |
| dmitriis | https://review.opendev.org/c/openstack/neutron-specs/+/870030/2/specs/2023.1/active-active-l3-gateway-with-multihoming.rst#340 | 14:17 |
| ralonsoh | so that's only limited to GW routers | 14:17 |
| dmitriis | the ecmp-symmetric-reply - yes. But we left it out of scope for now | 14:18 |
| ralonsoh | ok | 14:18 |
| dmitriis | the complexity is conntrack state synchronization | 14:18 |
| ralonsoh | one last question from me (that I don't see in the spec): is it possible to update a router to have multiple GWs and in the other way around, move from multiple GWs to only one? | 14:18 |
| dmitriis | yes, via update_external_gateways | 14:19 |
| dmitriis | we'd just leave one in the list when sending an update from the client | 14:20 |
| ralonsoh | I'll ask this in the spec to have more details about this | 14:20 |
| dmitriis | there is some complexity in implementing this in the API but I am working through that now | 14:20 |
| dmitriis | the main difficulty is compatibility with the current one-gateway logic | 14:20 |
| dmitriis | and making the new API smart about whether to update the gw_port_id field or not | 14:21 |
| slaweq | I think that rubasov addressed that in his spec | 14:21 |
| ralonsoh | I think this kind or architecture details can be discussed better in the spec | 14:21 |
| ralonsoh | ^^ slaweq right | 14:21 |
| slaweq | maybe You can check how it was proposed then | 14:21 |
| lajoskatona | +1 | 14:21 |
| dmitriis | slaweq: there was special handling for the first external_gateway_info in the list | 14:21 |
| mlavalle | imo this is a very cool RFE that I'll be very happy to continue discussing in the spec and the implementation | 14:22 |
| dmitriis | I have the same thing (adopted from the previous spec) | 14:22 |
| lajoskatona | yes the first one was left special to keep backward compatibility as I remember | 14:22 |
| dmitriis | mlavalle: thanks, I'm working on the mixin implementation now to see where things could fall apart but so far I am just learning the parts of the code base I haven't worked with | 14:22 |
| dmitriis | lajoskatona: yes, the mixin I am aiming to have is going to call to the parent methods with the first item and handle similarly but without touching the gw_port_id field of the router | 14:24 |
| dmitriis | but that's details | 14:24 |
| lajoskatona | ok | 14:24 |
| ralonsoh | folks, do you have any other question for dmitriis and fnordahl? | 14:25 |
| dmitriis | I am happy to answer any possible questions in the spec review | 14:25 |
| mlavalle | none from me | 14:25 |
| dmitriis | it's definitely something that needs careful consideration so I am very keen on receiving critical feedback :^) | 14:25 |
| amotoki | nothing from me. questions I had are already discussd :) | 14:25 |
| ralonsoh | yeah, this is why we have the spec review | 14:26 |
| lajoskatona | not from me, I started reading the spec, we can continue there I think | 14:26 |
| ralonsoh | so let's vote: | 14:26 |
| lajoskatona | +1 from me | 14:26 |
| ralonsoh | +1 for this RFE | 14:26 |
| mlavalle | dmitriis: yeah of course we are going to carry on the conversation in the spec | 14:26 |
| amotoki | +1 | 14:26 |
| obondarev | +1 | 14:26 |
| mlavalle | +1 | 14:26 |
| dmitriis | thanks for the support 👍 | 14:26 |
| ralonsoh | dmitriis, fnordahl thanks for your RFE, I'll update the launchpad bug now | 14:27 |
| ralonsoh | the RFE is approved | 14:27 |
| fnordahl | thanks! | 14:27 |
| ralonsoh | let's continue the review in the spec | 14:27 |
| slaweq | +1 | 14:27 |
| dmitriis | + | 14:27 |
| ralonsoh | is there any other topic to be discussed today? | 14:28 |
| mlavalle | not from me | 14:28 |
| dmitriis | I have a question around attaching routers to segmented networks | 14:28 |
| ralonsoh | dmitriis, we can have this discussion outside the meeting | 14:29 |
| dmitriis | ralonsoh: ack | 14:29 |
| dmitriis | no other questions | 14:29 |
| ralonsoh | thank you all for attending, have a nice weekend! | 14:29 |
| dmitriis | tyvm | 14:30 |
| ralonsoh | #endmeeting | 14:30 |
| opendevmeet | Meeting ended Fri Jan 27 14:30:03 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:30 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-01-27-14.00.html | 14:30 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-01-27-14.00.txt | 14:30 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-01-27-14.00.log.html | 14:30 |
| fnordahl | \o thanks all, and cheers! | 14:30 |
| mlavalle | dmitriis, fnordahl: thanks for this very cool rfe! | 14:30 |
| lajoskatona | o/ | 14:30 |
| slaweq | o/ | 14:30 |
| mlavalle | o/ | 14:30 |
| amotoki | o/ | 14:30 |
| obondarev | o/ | 14:30 |
| dmitriis | o/ | 14:30 |
| ralonsoh | dmitriis, so I think you are referring to a launchpad bug | 14:30 |
| ralonsoh | If I'm not wrong | 14:30 |
| dmitriis | https://bugs.launchpad.net/neutron/+bug/2003842 | 14:30 |
| ralonsoh | yes, this one. | 14:31 |
| ralonsoh | this is not supported | 14:31 |
| dmitriis | yes, I am curious as to how it relates to the FIPs on RPNs | 14:31 |
| dmitriis | https://review.opendev.org/c/openstack/neutron-specs/+/486450/17/specs/victoria/routed-networks-floating-ips.rst | 14:31 |
| dmitriis | https://review.opendev.org/c/openstack/neutron/+/669395/ | 14:31 |
| dmitriis | https://review.opendev.org/q/topic:bug%252F1667329 | 14:31 |
| dmitriis | effectively, if we have FIPs on RPNs, then it implies attaching routers to RPNs | 14:31 |
| dmitriis | so, we can treat this as "a missing feature" or "not supported by design" - I am wondering which one :^) | 14:32 |
| ralonsoh | dmitriis, I need to check that code, I barely remember it | 14:32 |
| ralonsoh | and I've never used it | 14:32 |
| dmitriis | yeah, the FIPs on RPN spec just added a new service subnet type and it needs extra improvements done in the NDR code to actually have multi-segment awareness | 14:33 |
| dmitriis | so it's far from being complete as as it is | 14:33 |
| ralonsoh | dmitriis, exactly, that RFE was never completed | 14:33 |
| ralonsoh | dmitriis, actually I'll propose to revert this code | 14:34 |
| dmitriis | ok, so I suppose we can treat it as a "missing feature" type scenario unless we don't want this kind of design ever implemented | 14:34 |
| ralonsoh | dmitriis, right | 14:35 |
| ralonsoh | and btw, I dont' remember if those FIPs were "bound" to a router | 14:35 |
| ralonsoh | but used somehow to handle the NATing done outside Neutron | 14:35 |
| ralonsoh | but I'm still reviewing again the spec | 14:35 |
| dmitriis | in future work it says: "For some operators, there is a desire to allow for floating IP's to be associated to a port without first connecting a router to an external network and a tenant network." | 14:36 |
| ralonsoh | exactly | 14:37 |
| dmitriis | so I suppose that was something they wanted to do next | 14:37 |
| ralonsoh | in any case, I pushed a patch 1 year ago | 14:37 |
| ralonsoh | to support legacy routers with routed provided networks | 14:37 |
| ralonsoh | but that was tested and implemented only for ML2/OVS and the L3 agent | 14:37 |
| ralonsoh | not OVN at all | 14:37 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/791178 | 14:38 |
| ralonsoh | (I'm not proud of this patch) | 14:38 |
| dmitriis | ralonsoh: ok, I wasn't aware of the history. But to be honest, supporting RPN is not my main focus now | 14:38 |
| dmitriis | I was just wondering if I need to plan for it to work in the future | 14:39 |
| ralonsoh | IMO, I don't think so | 14:39 |
| ralonsoh | if you use routed provider networks, that means you are not using the L3 capabilities of Neutron | 14:39 |
| dmitriis | ok, so then I'll table it for now. I have enough complexity in the spec and I wanted to make sure I don't break anything (including RPN support if it was there) | 14:39 |
| dmitriis | ralonsoh: well, the RPN support can be useful to avoid having to implement EVPN at the fabric side | 14:40 |
| dmitriis | otherwise it's both overlays at the OpenStack/OVN side and the l3 DC fabric as well | 14:41 |
| dmitriis | but it also seems to me that supporting RPN like this is pushing complexity around | 14:42 |
| ralonsoh | well, the goal of RPN was to simplify the Neutron architecture | 14:42 |
| ralonsoh | (kind of) | 14:42 |
| dmitriis | thanks a lot for discussing it with me ralonsoh | 14:43 |
| ralonsoh | a pleasure | 14:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP - Improve sync_ha_chassis_group https://review.opendev.org/c/openstack/neutron/+/872023 | 15:19 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Accept HA chassis group commands in HAChassisGroupAdd* https://review.opendev.org/c/openstack/ovsdbapp/+/871836 | 15:29 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Accept HA chassis group commands in HAChassisGroupAdd* https://review.opendev.org/c/openstack/ovsdbapp/+/871836 | 15:37 |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Accept HA chassis group commands in HAChassisGroupAdd* https://review.opendev.org/c/openstack/ovsdbapp/+/871836 | 15:38 |
| opendevreview | Merged openstack/neutron stable/zed: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871908 | 16:52 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Improve "sync_ha_chassis_group" method https://review.opendev.org/c/openstack/neutron/+/872023 | 17:04 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron master: [OVN] Allow logging all traffic related to an ACL https://review.opendev.org/c/openstack/neutron/+/871096 | 17:07 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Improve "sync_ha_chassis_group" method https://review.opendev.org/c/openstack/neutron/+/872023 | 17:13 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP - Add ``OVNGatewayHAChassisGroup`` scheduler class https://review.opendev.org/c/openstack/neutron/+/872033 | 17:38 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Implementation of OVN Neutron Agent https://review.opendev.org/c/openstack/neutron/+/870024 | 17:49 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] New OVN Neutron Agent extension: QoS for HWOL https://review.opendev.org/c/openstack/neutron/+/870115 | 17:49 |
| opendevreview | Merged openstack/neutron stable/xena: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871990 | 18:04 |
| opendevreview | Merged openstack/neutron stable/yoga: Never raise an exception in notify() https://review.opendev.org/c/openstack/neutron/+/871909 | 18:17 |
| *** dasm is now known as dasm|off | 21:35 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!