| opendevreview | Merged openstack/neutron stable/2023.1: Forbid the subnet gateway IP deletion if a router interface is attached https://review.opendev.org/c/openstack/neutron/+/905666 | 01:47 |
|---|---|---|
| opendevreview | Merged openstack/neutron master: dhcp: improving log level of cleanup stale devices https://review.opendev.org/c/openstack/neutron/+/905207 | 07:24 |
| opendevreview | Merged openstack/neutron master: Add firewall_v2 to extensions supported by ovn https://review.opendev.org/c/openstack/neutron/+/905416 | 07:47 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: DNM == WIP == Define the namespace for RPC metadata https://review.opendev.org/c/openstack/neutron/+/905309 | 07:50 |
| lajoskatona | ykarel: Hi, shall I ask for some help regarding tempest and how the networkfeatur-enabled/api_extensions list is generated? | 08:15 |
| lajoskatona | ykarel: I have a patch for taas scenario (and API tests) and added job for OVN: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004/21/zuul.d/master_jobs.yaml#1542 | 08:15 |
| lajoskatona | ykarel: but for OVN the tests are skipped as in tempest.conf tap_mirror is not in the list: https://b6c435e77b767f6a22d6-a058aa35e64e01a4aa578bfd55ac6048.ssl.cf1.rackcdn.com/886004/21/check/neutron-tempest-plugin-tap-as-a-service-ovn/9f9c25e/controller/logs/tempest_conf.txt | 08:16 |
| lajoskatona | ykarel: but what I don't understand is that in local.conf the NETWORK_API_EXTENSIONS contains my extension: https://b6c435e77b767f6a22d6-a058aa35e64e01a4aa578bfd55ac6048.ssl.cf1.rackcdn.com/886004/21/check/neutron-tempest-plugin-tap-as-a-service-ovn/9f9c25e/controller/logs/local_conf.txt | 08:17 |
| ykarel | lajoskatona, hi looking | 08:17 |
| lajoskatona | ykarel: so if you have any idea what am I missing would be very helpful :-) | 08:17 |
| lajoskatona | ykarel: thanks | 08:21 |
| ykarel | lajoskatona, i don't see those extensions in ovn supported lists ML2_SUPPORTED_API_EXTENSIONS or ML2_SUPPORTED_API_EXTENSIONS_OVN_L3 | 08:26 |
| ykarel | so those get's filtered out from what you set in NETWORK_API_EXTENSIONS | 08:27 |
| ykarel | https://opendev.org/openstack/devstack/src/branch/master/lib/neutron_plugins/ovn_agent#L431-L459 where that filtering happens | 08:28 |
| lajoskatona | ykarel: ok, so I have to add my extension to ML2_SUPPORTED_API_EXTENSIONS or to ML2_SUPPORTED_API_EXTENSIONS_OVN_L3? Let me check | 08:29 |
| opendevreview | Merged openstack/neutron master: Cleanup setup.py and requirements https://review.opendev.org/c/openstack/neutron/+/905417 | 08:30 |
| ykarel | lajoskatona, yes | 08:37 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: If method ``set_netns`` fails, restore previous device namespace https://review.opendev.org/c/openstack/neutron/+/905836 | 08:42 |
| noonedeadpunk | Hey folks! I'm trying to map Availability Zone functionality/behaviour between OVS and OVN. So we do currently do have strettched tenant networks in OVS, and each network node (that's running l3/dhcp agents) has basically access to same l2 networks. | 09:17 |
| noonedeadpunk | So we're using scheduling to spawn l3 namespaces in different AZs by default | 09:17 |
| noonedeadpunk | I assume, that for this scenario in OVN I do need to set all gateways to be part of all AZs? | 09:18 |
| noonedeadpunk | And then there's kinda no way to ensure where/how actually routers will be distributed among gateways. But regardless in case of full AZ outage it somehow (split brain???) will just use available gateways for routers? | 09:19 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Add tap_mirror to extension to OVN supported extensions https://review.opendev.org/c/openstack/neutron/+/905840 | 09:24 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004 | 09:25 |
| noonedeadpunk | slaweq: maybe you are able to help me with that? (∩‿∩) | 09:39 |
| slaweq | noonedeadpunk sorry, I can't now but maybe lucasagomes or ralonsoh can will be able to help You with this | 09:43 |
| opendevreview | Merged openstack/ovn-bgp-agent master: Remove copy&paste code from ensure_arp_ndp_enabled_for_bridge https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905793 | 09:43 |
| ralonsoh | in a meeting, I'll check the logs after it | 09:43 |
| noonedeadpunk | It's not urgent jsut in case | 09:45 |
| noonedeadpunk | but would be great to get better understanding and if some of my assumptions are wrong or not | 09:45 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-bgp-agent stable/2023.2: Remove copy&paste code from ensure_arp_ndp_enabled_for_bridge https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905733 | 09:47 |
| noonedeadpunk | as couple of weeks ago (due to holidays) nobody was around : https://meetings.opendev.org/irclogs/%23openstack-neutron/%23openstack-neutron.2024-01-03.log.html#t2024-01-03T10:52:48 | 09:50 |
| opendevreview | Fernando Royo proposed openstack/ovn-bgp-agent master: Add support to PF OVN LBs for NB Driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905504 | 09:55 |
| sahid | o? | 10:01 |
| sahid | o? | 10:01 |
| lucasagomes | noonedeadpunk, if u pass mulitple availability-zone-hints when creating a router, ML2/OVN will take that in consideration when it schedules the gateway ports to be distributed to nodes that belongs to these AZs | 10:01 |
| sahid | o/ | 10:01 |
| lucasagomes | noonedeadpunk, but only one instance of that port will be active at a time | 10:02 |
| noonedeadpunk | lucasagomes: aha, but for that each gateway should be set to a single AZ? | 10:04 |
| noonedeadpunk | As I guess there's no other way how it may know where gateway actually is | 10:04 |
| noonedeadpunk | So basically if I should `availability-zones=az0:az1:az2` for each gateway, or I am able to set only "appropriate" AZ and gateway will still be able to serve traffic from other AZs given hint is provided? | 10:07 |
| lucasagomes | noonedeadpunk, you can set multiple AZs for each gateway, if at least one of them matches the hint given when creating the router, ML2/OVN will consider that node as a candidate to schedule the gateway ports onto | 10:08 |
| lucasagomes | noonedeadpunk, one quick thing as well, there's another flag called "enable-chassis-as-gw" that you should set on the gateway nodes, that tells ML2/OVN what node is and what node is not a gateway | 10:09 |
| lucasagomes | So say u have a node that belongs to the same AZ but u don't wont the gateway ports scheduled there | 10:10 |
| noonedeadpunk | yeah, that part with enable-chassis-as-gw I know | 10:10 |
| lucasagomes | U don't set the enable-chassis-as-gw flag to that node and it won't be considered a candidate | 10:10 |
| lucasagomes | But yeah, u can add gw to multiple AZs and they will serve traffic for the other AZs | 10:10 |
| lucasagomes | AFAIRC | 10:10 |
| lucasagomes | This is just a way to tell OVN where to put the ports, we do not block any traffic with flows to restrict it to the AZs itself | 10:11 |
| noonedeadpunk | availability-zones flag is always complimentary to enable-chassis-as-gw iirc | 10:11 |
| lucasagomes | noonedeadpunk, yes | 10:11 |
| lucasagomes | if u want to restrict traffic within zones, OVN itself (the OVN project, not ML2/OVN) has a thing called "transport zones" | 10:11 |
| lucasagomes | which u can do that | 10:12 |
| lucasagomes | but the AZs in Ml2/OVN is just about knowing where to schedules the ports onto | 10:12 |
| noonedeadpunk | aha, I see. Basically, what I want to do, is same we have with OVS now. Like default_availability_zones = az1,az2,az3 and then each namespace is present at least in 1 AZ | 10:13 |
| noonedeadpunk | I guess for that, based on your answer, each gateway should be set to it's own AZ | 10:13 |
| noonedeadpunk | and traffic between AZs is not prohibited by default | 10:13 |
| lucasagomes | Yeah, that's my understanding too | 10:13 |
| noonedeadpunk | So given default_availability_zones = az1,az2,az3 router ports will be created at least in 2 different AZs? | 10:14 |
| noonedeadpunk | but only one will be active | 10:14 |
| lucasagomes | Yeah, so you want to have 1 AZ per gw, so there's at least 1 port active on each AZ | 10:14 |
| noonedeadpunk | And if we set each gateway to availability_zones = az1:az2:az3 - then they will be randomly selected? | 10:14 |
| lucasagomes | Yeah, there's an algorithm that checks the number of ports on each gateway node and will schedule the next port on the one with the least amount | 10:15 |
| noonedeadpunk | "so there's at least 1 port active on each AZ" -> so there can be multiple active ports per router? | 10:15 |
| ralonsoh | noonedeadpunk, sorry, I finished my meeting now | 10:16 |
| lucasagomes | sorry, that was confused... not AFAIK only 1 gw port per router | 10:17 |
| ralonsoh | I see lucasagomes is already answering you | 10:17 |
| noonedeadpunk | yeah, I think things are way more clear now. I just for some reason though that cross-AZ trafic is not possible by default, unless gateway is set to serve in all azs | 10:18 |
| noonedeadpunk | thanks a lot lucasagomes and ralonsoh :) | 10:18 |
| ralonsoh | btw, remember that now we fail to scheduler a rotuer port if there are not available AZs routers | 10:19 |
| lucasagomes | noonedeadpunk, np, let us know later if it worked on ur env | 10:19 |
| ralonsoh | that means if you choose a AZ that is not assigned to any router, you won't get any router port | 10:19 |
| ralonsoh | lucasagomes, talking about this subject | 10:20 |
| ralonsoh | please check https://review.opendev.org/c/openstack/neutron/+/893653 | 10:20 |
| lucasagomes | ralonsoh, will do | 10:21 |
| lucasagomes | interesting, will review it | 10:21 |
| noonedeadpunk | ralonsoh: "if you choose a AZ that is not assigned to any router" -> you meant assigned to any gateway node? | 10:21 |
| noonedeadpunk | *not assigned to any gateway | 10:22 |
| ralonsoh | yes, if there are not chassis with the requested AZ, before Bobcat we used to take all available GWs | 10:22 |
| noonedeadpunk | ++ | 10:22 |
| ralonsoh | but now we don't and fail scheduling them | 10:22 |
| ralonsoh | (with the corresponding warning message) | 10:23 |
| noonedeadpunk | ok, yes, that is fair change | 10:23 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: DNM == WIP == Define the namespace for RPC metadata https://review.opendev.org/c/openstack/neutron/+/905309 | 10:24 |
| noonedeadpunk | lucasagomes: I will for sure:) Though it might take some time, as currently jsut trying to come up with hopefully better design then we had with OVS | 10:26 |
| noonedeadpunk | another thing we'd also need to test is vpnaas support as I see it being finally merged :) | 10:32 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/neutron-vpnaas master: Remove `restart-by-peer` from dpd actions https://review.opendev.org/c/openstack/neutron-vpnaas/+/878321 | 10:34 |
| opendevreview | Felix Huettner proposed openstack/neutron master: ovn-l3 scheduler: calculate load of chassis per priority https://review.opendev.org/c/openstack/neutron/+/893653 | 11:04 |
| opendevreview | Felix Huettner proposed openstack/neutron master: ovn-l3: reschedule lower priorities https://review.opendev.org/c/openstack/neutron/+/893654 | 11:04 |
| opendevreview | Felix Huettner proposed openstack/neutron master: ovn-l3: reschedule priorities on new chassis https://review.opendev.org/c/openstack/neutron/+/893655 | 11:04 |
| opendevreview | Felix Huettner proposed openstack/neutron master: ovn-l3 router scheduler: reproduce scheduling issue https://review.opendev.org/c/openstack/neutron/+/893656 | 11:04 |
| opendevreview | Felix Huettner proposed openstack/neutron master: ovn-l3: implement caching for Scheduler https://review.opendev.org/c/openstack/neutron/+/893657 | 11:04 |
| opendevreview | Felix Huettner proposed openstack/neutron master: ovn-l3: try to keep routers at current chassis https://review.opendev.org/c/openstack/neutron/+/893658 | 11:04 |
| opendevreview | Felix Huettner proposed openstack/neutron master: ovn-l3: value the higher priorities when scheduling https://review.opendev.org/c/openstack/neutron/+/893659 | 11:04 |
| opendevreview | Martin Kopec proposed openstack/neutron-tempest-plugin master: Fix network sorting in API tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/905853 | 11:09 |
| ralonsoh | rubasov, hello! I'm checking https://review.opendev.org/c/openstack/neutron/+/905125 | 11:22 |
| ralonsoh | along with http://www.openvswitch.org//ovs-vswitchd.conf.db.5.pdf | 11:22 |
| ralonsoh | (I've reviewed this documentation several times) | 11:22 |
| ralonsoh | "For an access port, the port’s implicitly tagged VLAN" | 11:22 |
| ralonsoh | I think we should also define tag=0 for the parent port, to accept only untagged traffic | 11:23 |
| *** ravlew is now known as Guest14423 | 11:33 | |
| opendevreview | Fernando Royo proposed openstack/ovn-bgp-agent master: Fix OVN LB Delete events for NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905783 | 11:35 |
| opendevreview | Fernando Royo proposed openstack/ovn-bgp-agent master: Fix OVN LB Delete events for NB driver https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905783 | 11:55 |
| rubasov | ralonsoh: hello! thanks for looking! I'm okay with setting tag=0 and vlan_mode=access for each tpt. I believed that tag=unspecified and tag=0 are equivalent (at least in vlan_mode=access), but now I also doublechecked man ovs-vswitchd.conf.db, and surprisingly it does not seem to define what tag=unspecified means (or at least I could not find it). So yes, it's likely better to be explicit and | 12:23 |
| rubasov | set tag=0. | 12:23 |
| rubasov | in my test environment the tpt keeps working if I set both vlan_mode=access and tag=0 (as it should) | 12:24 |
| ralonsoh | rubasov, perfect | 12:36 |
| ralonsoh | one quick question (because you implemented this plugin) | 12:36 |
| rubasov | shoot (however I was not really the implementor, but maybe I know) | 12:37 |
| ralonsoh | couldn't be possible to have one single port with mode=trunk and trunk=0,vlan1,vlan2,etc? | 12:37 |
| ralonsoh | OVS can filter with one single port all needed VLANs | 12:37 |
| ralonsoh | that could avoid the creation of many ports in OVS | 12:37 |
| rubasov | the vlan remapping between br-ints internal vlans and the user trunks segmentation-ids would be problematic | 12:38 |
| rubasov | the usual ovs pattern to remap a vlan requires two bridges | 12:38 |
| ralonsoh | this could be done with the same rules we have | 12:38 |
| ralonsoh | yes, with 2 bridges as is now | 12:38 |
| ralonsoh | but instead of having multiple patch ports between br-int and br-trunk | 12:39 |
| ralonsoh | just one | 12:39 |
| rubasov | I'm not saying the remapping would be impossible with pure openflow rules, but it would lead to a very complicated flow set I believe | 12:40 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: DNM == WIP == Define the namespace for RPC metadata https://review.opendev.org/c/openstack/neutron/+/905309 | 12:40 |
| ralonsoh | probably yes, because you can't filter by inport | 12:41 |
| rubasov | yes, exactly | 12:41 |
| ralonsoh | but with multiple subports (100) | 12:41 |
| ralonsoh | there are a lot of problems with timeouts | 12:42 |
| ralonsoh | that could be cleaner and faster | 12:42 |
| ralonsoh | in any case, I'll open a LP just to track this possible improvement | 12:42 |
| rubasov | that's a kind of documented scaling limitation: https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling | 12:44 |
| rubasov | which can be tackled quite well by raising rpc_response_timeout | 12:44 |
| ralonsoh | and we hit that several times in our internal CI | 12:44 |
| ralonsoh | with 100-200 subports | 12:44 |
| rubasov | especially with the recent change about having rpc aliveness checks while waiting for a response I believe it's quite safe to raise that to 10+ times the default | 12:46 |
| ralonsoh | yes but is still an issue to wait for 200 seconds for a VM to be ready | 12:46 |
| rubasov | yes, but isn't a large part of that wait on the server side? we can't optimize that away from the agent | 12:49 |
| ralonsoh | the server side is waiting for the plug events form the agent | 13:00 |
| ralonsoh | if we plug one single port, that will be much faster | 13:00 |
| ralonsoh | in any case, I'll try to do a POC, "just for fun" | 13:01 |
| opendevreview | Bence Romsics proposed openstack/neutron master: Set trunk parent port as access port in ovs to avoid loop https://review.opendev.org/c/openstack/neutron/+/905125 | 13:54 |
| rubasov | ^ uploaded a new ps with tag=0 | 14:02 |
| rubasov | regarding the optimization we just talked about: I believe the main problem is here: https://opendev.org/openstack/neutron/src/branch/master/neutron/services/trunk/rpc/server.py#L83 and in turn in def _process_trunk_subport_bindings() where we have to update all subport bindings and I believe this is a limitation of the api model and not something we can change from the agent side | 14:04 |
| ralonsoh | rubasov, and the subport.plug? | 14:04 |
| ralonsoh | what I was proposing is something like this | 14:04 |
| ralonsoh | TrunkParentPort.plug(br_int, tag=0) | 14:05 |
| ralonsoh | by default Trunk will be tag=0 | 14:05 |
| ralonsoh | SubPort.plug will call super() with tag=self.segmentation_id | 14:05 |
| ralonsoh | right? | 14:05 |
| ralonsoh | about the optimizations: right but I don't know if the subport bindings is the time consuming part and not the OVS port creation | 14:07 |
| ralonsoh | but yes, port binding in the server could be very time consuming | 14:08 |
| opendevreview | Bence Romsics proposed openstack/neutron master: Set trunk parent port as access port in ovs to avoid loop https://review.opendev.org/c/openstack/neutron/+/905125 | 14:39 |
| opendevreview | Sahid Orentino Ferdjaoui proposed openstack/neutron master: dhcp: ensure that cleaning DHCP process for segment 0 happens first https://review.opendev.org/c/openstack/neutron/+/905617 | 14:40 |
| opendevreview | Takashi Kajinami proposed openstack/tap-as-a-service master: Bump hacking https://review.opendev.org/c/openstack/tap-as-a-service/+/905878 | 14:45 |
| opendevreview | Sahid Orentino Ferdjaoui proposed openstack/neutron master: dhcp: ensure that cleaning DHCP process with one segment happens first https://review.opendev.org/c/openstack/neutron/+/905617 | 14:47 |
| opendevreview | Hervé Beraud proposed openstack/networking-sfc master: bump eventlet to latest version that support python 3.12 https://review.opendev.org/c/openstack/networking-sfc/+/905923 | 15:11 |
| opendevreview | Hervé Beraud proposed openstack/neutron master: bump eventlet to latest version that support python 3.12 https://review.opendev.org/c/openstack/neutron/+/905924 | 15:12 |
| opendevreview | Hervé Beraud proposed openstack/neutron-dynamic-routing master: bump eventlet to latest version that support python 3.12 https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/905925 | 15:12 |
| opendevreview | Hervé Beraud proposed openstack/neutron-fwaas master: bump eventlet to latest version that support python 3.12 https://review.opendev.org/c/openstack/neutron-fwaas/+/905926 | 15:13 |
| opendevreview | Hervé Beraud proposed openstack/neutron-tempest-plugin master: bump eventlet to latest version that support python 3.12 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/905927 | 15:15 |
| opendevreview | Hervé Beraud proposed openstack/os-ken master: bump eventlet to latest version that support python 3.12 https://review.opendev.org/c/openstack/os-ken/+/905929 | 15:18 |
| opendevreview | Miguel Lavalle proposed openstack/neutron master: Router flavors and service type for OVN https://review.opendev.org/c/openstack/neutron/+/883988 | 15:34 |
| opendevreview | Merged openstack/neutron master: ovn-l3 scheduler: calculate load of chassis per priority https://review.opendev.org/c/openstack/neutron/+/893653 | 15:34 |
| opendevreview | Merged openstack/neutron master: ovn-l3: reschedule lower priorities https://review.opendev.org/c/openstack/neutron/+/893654 | 15:34 |
| mlavalle | ralonsoh, lajoskatona: I just fixed the merging conflict in https://review.opendev.org/c/openstack/neutron/+/883988/. Please +2 again when you have a chance. Thanks! | 15:37 |
| ralonsoh | sure | 15:37 |
| opendevreview | Miguel Lavalle proposed openstack/neutron master: [PoC][DNM] Enable HA for OVN router flavors https://review.opendev.org/c/openstack/neutron/+/901513 | 15:44 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: DNM == WIP == Define the namespace for RPC metadata https://review.opendev.org/c/openstack/neutron/+/905309 | 15:51 |
| opendevreview | Hervé Beraud proposed openstack/ovn-bgp-agent master: bump eventlet to latest version that support python 3.12 https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905968 | 15:54 |
| tkajinam | is taas now part of the official projects in neutron, right ? https://opendev.org/openstack/tap-as-a-service | 15:58 |
| tkajinam | I just noticed the repository contains very old stable branches like stable/ocata. Looking at the releases repo, the repository was not controlled by the releases repo until yoga and some manual update may be needed to retire old branches in this repo | 15:59 |
| opendevreview | Merged openstack/neutron-lib master: Bump hacking https://review.opendev.org/c/openstack/neutron-lib/+/905718 | 16:03 |
| opendevreview | Bence Romsics proposed openstack/neutron master: Set trunk parent port as access port in ovs to avoid loop https://review.opendev.org/c/openstack/neutron/+/905125 | 16:32 |
| *** gthiemon1e is now known as gthiemonge | 16:41 | |
| opendevreview | Merged openstack/neutron-vpnaas master: Update python classifier with py3.10 & py3.11 in setup.cfg https://review.opendev.org/c/openstack/neutron-vpnaas/+/905302 | 17:02 |
| haleyb | mnaser: you're on the neutron-vpnaas core team right? i was trying to find someone to take https://bugs.launchpad.net/neutron/+bug/2049624 but don't know if the contributor doc was up to date | 17:20 |
| opendevreview | Merged openstack/neutron master: [OVN] Update lsp host id when virtual parent moves https://review.opendev.org/c/openstack/neutron/+/896883 | 18:08 |
| opendevreview | Merged openstack/neutron master: Make get_ports RPC method common for the DHCP and Metadata agent https://review.opendev.org/c/openstack/neutron/+/904872 | 18:35 |
| noonedeadpunk | hi again. Question - how IPv6 should be handled with OVN? Like with OVS we have had a bgp dr-agent as traffic was coming through l3 agents and subnet pool was used then. I was kinda wondering, if OVN gateways are not co-located with computes but a standalone nodes - should we then be using ovn-bgp-agent instead? Or maybe for OVN we don't need anything like that as there're not really a nat? | 18:39 |
| frickler | noonedeadpunk: for me, OVN + bgp dragent is working the same way it did with OVS. that's without using DVR though | 19:09 |
| noonedeadpunk | frickler: so computes don't have access to provider networks? | 19:09 |
| noonedeadpunk | (directly) | 19:10 |
| noonedeadpunk | but that's interesting | 19:10 |
| noonedeadpunk | I would never thought it will work for some reason | 19:11 |
| frickler | well we don't have actual provider networks, just a single public (=internet) network, and we explicitly don't want computes to be connected to that | 19:11 |
| noonedeadpunk | yeah, ok, so more or less same usecase I have | 19:11 |
| frickler | it needed a bit of patching for n-d-r, but that should have been backported to at least zed or yoga I think | 19:11 |
| noonedeadpunk | ok, awesome then | 19:12 |
| noonedeadpunk | thanks for the info! | 19:12 |
| frickler | there's also some doc for this usecase if you haven't seen it (not ovn-specific though) https://docs.openstack.org/neutron-dynamic-routing/latest/install/usecase-ipv6.html | 19:15 |
| opendevreview | Jakub Libosvar proposed openstack/ovn-bgp-agent master: Refactor ensure_routing_table_for_bridge https://review.opendev.org/c/openstack/ovn-bgp-agent/+/905795 | 19:19 |
| haleyb | ralonsoh: can you take a look at https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/894027 ? i haven't seen lajos around the past couple of days and think that should be good to merge since the neutron code did already | 19:50 |
| opendevreview | Merged openstack/neutron master: Router flavors and service type for OVN https://review.opendev.org/c/openstack/neutron/+/883988 | 20:27 |
| opendevreview | Miro Tomaska proposed openstack/neutron stable/2023.2: Make get_ports RPC method common for the DHCP and Metadata agent https://review.opendev.org/c/openstack/neutron/+/905906 | 20:33 |
| opendevreview | Brian Haley proposed openstack/neutron master: Remove string support in install_instructions https://review.opendev.org/c/openstack/neutron/+/905755 | 21:08 |
| opendevreview | Brian Haley proposed openstack/neutron master: Fix keyword-arg-before-vararg warnings https://review.opendev.org/c/openstack/neutron/+/906006 | 21:09 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!