Wednesday, 2024-01-17

opendevreviewMerged openstack/neutron stable/2023.1: Forbid the subnet gateway IP deletion if a router interface is attached  https://review.opendev.org/c/openstack/neutron/+/90566601:47
opendevreviewMerged openstack/neutron master: dhcp: improving log level of cleanup stale devices  https://review.opendev.org/c/openstack/neutron/+/90520707:24
opendevreviewMerged openstack/neutron master: Add firewall_v2 to extensions supported by ovn  https://review.opendev.org/c/openstack/neutron/+/90541607:47
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM == WIP == Define the namespace for RPC metadata  https://review.opendev.org/c/openstack/neutron/+/90530907:50
lajoskatonaykarel: Hi, shall I ask for some help regarding tempest and how the networkfeatur-enabled/api_extensions list is generated?08:15
lajoskatonaykarel: 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#154208:15
lajoskatonaykarel: 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.txt08:16
lajoskatonaykarel: 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.txt08:17
ykarellajoskatona, hi looking08:17
lajoskatonaykarel: so if you have any idea what am I missing would be very helpful :-)08:17
lajoskatonaykarel: thanks08:21
ykarellajoskatona, i don't see those extensions in ovn supported lists ML2_SUPPORTED_API_EXTENSIONS or ML2_SUPPORTED_API_EXTENSIONS_OVN_L308:26
ykarelso those get's filtered out from what you set in NETWORK_API_EXTENSIONS08:27
ykarelhttps://opendev.org/openstack/devstack/src/branch/master/lib/neutron_plugins/ovn_agent#L431-L459 where that filtering happens08:28
lajoskatonaykarel: ok, so I have to add my extension to ML2_SUPPORTED_API_EXTENSIONS or to ML2_SUPPORTED_API_EXTENSIONS_OVN_L3? Let me check08:29
opendevreviewMerged openstack/neutron master: Cleanup setup.py and requirements  https://review.opendev.org/c/openstack/neutron/+/90541708:30
ykarellajoskatona, yes08:37
opendevreviewRodolfo Alonso proposed openstack/neutron master: If method ``set_netns`` fails, restore previous device namespace  https://review.opendev.org/c/openstack/neutron/+/90583608:42
noonedeadpunkHey 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
noonedeadpunkSo we're using scheduling to spawn l3 namespaces in different AZs by default09:17
noonedeadpunkI assume, that for this scenario in OVN I do need to set all gateways to be part of all AZs?09:18
noonedeadpunkAnd 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
opendevreviewLajos Katona proposed openstack/neutron master: Add tap_mirror to extension to OVN supported extensions  https://review.opendev.org/c/openstack/neutron/+/90584009:24
opendevreviewLajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/88600409:25
noonedeadpunkslaweq: maybe you are able to help me with that? (∩‿∩)09:39
slaweqnoonedeadpunk sorry, I can't now but maybe lucasagomes or ralonsoh can will be able to help You with this09:43
opendevreviewMerged 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/+/90579309:43
ralonsohin a meeting, I'll check the logs after it09:43
noonedeadpunkIt's not urgent jsut in case09:45
noonedeadpunkbut would be great to get better understanding and if some of my assumptions are wrong or not 09:45
opendevreviewLuis 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/+/90573309:47
noonedeadpunkas 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:4809:50
opendevreviewFernando 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/+/90550409:55
sahido?10:01
sahido?10:01
lucasagomesnoonedeadpunk, 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 AZs10:01
sahido/10:01
lucasagomesnoonedeadpunk, but only one instance of that port will be active at a time10:02
noonedeadpunklucasagomes: aha, but for that each gateway should be set to a single AZ?10:04
noonedeadpunkAs I guess there's no other way how it may know where gateway actually is10:04
noonedeadpunkSo 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
lucasagomesnoonedeadpunk, 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 onto10:08
lucasagomesnoonedeadpunk, 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 gateway10:09
lucasagomesSo say u have a node that belongs to the same AZ but u don't wont the gateway ports scheduled there10:10
noonedeadpunkyeah, that part with enable-chassis-as-gw I know10:10
lucasagomesU don't set the enable-chassis-as-gw flag to that node and it won't be considered a candidate10:10
lucasagomesBut yeah, u can add gw to multiple AZs and they will serve traffic for the other AZs10:10
lucasagomesAFAIRC10:10
lucasagomesThis 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 itself10:11
noonedeadpunkavailability-zones flag is always complimentary to enable-chassis-as-gw iirc10:11
lucasagomesnoonedeadpunk, yes10:11
lucasagomesif u want to restrict traffic within zones, OVN itself (the OVN project, not ML2/OVN) has a thing called "transport zones"10:11
lucasagomeswhich u can do that10:12
lucasagomesbut the AZs in Ml2/OVN is just about knowing where to schedules the ports onto10:12
noonedeadpunkaha, 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 AZ10:13
noonedeadpunkI guess for that, based on your answer, each gateway should be set to it's own AZ10:13
noonedeadpunkand traffic between AZs is not prohibited by default10:13
lucasagomesYeah, that's my understanding too10:13
noonedeadpunkSo given default_availability_zones = az1,az2,az3 router ports will be created at least in 2 different AZs?10:14
noonedeadpunkbut only one will be active10:14
lucasagomesYeah, so you want to have 1 AZ per gw, so there's at least 1 port active on each AZ10:14
noonedeadpunkAnd if we set each gateway to availability_zones = az1:az2:az3 - then they will be randomly selected?10:14
lucasagomesYeah, 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 amount10:15
noonedeadpunk"so there's at least 1 port active on each AZ" -> so there can be multiple active ports per router?10:15
ralonsohnoonedeadpunk, sorry, I finished my meeting now10:16
lucasagomessorry, that was confused... not AFAIK only 1 gw port per router10:17
ralonsohI see lucasagomes is already answering you10:17
noonedeadpunkyeah, 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 azs10:18
noonedeadpunkthanks a lot lucasagomes and ralonsoh :)10:18
ralonsohbtw, remember that now we fail to scheduler a rotuer port if there are not available AZs routers10:19
lucasagomesnoonedeadpunk, np, let us know later if it worked on ur env10:19
ralonsohthat means if you choose a AZ that is not assigned to any router, you won't get any router port10:19
ralonsohlucasagomes, talking about this subject10:20
ralonsohplease check https://review.opendev.org/c/openstack/neutron/+/89365310:20
lucasagomesralonsoh, will do10:21
lucasagomesinteresting, will review it10:21
noonedeadpunkralonsoh: "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 gateway10:22
ralonsohyes, if there are not chassis with the requested AZ, before Bobcat we used to take all available GWs10:22
noonedeadpunk++10:22
ralonsohbut now we don't and fail scheduling them10:22
ralonsoh(with the corresponding warning message)10:23
noonedeadpunkok, yes, that is fair change10:23
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM == WIP == Define the namespace for RPC metadata  https://review.opendev.org/c/openstack/neutron/+/90530910:24
noonedeadpunklucasagomes: 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 OVS10:26
noonedeadpunkanother thing we'd also need to test is vpnaas support as I see it being finally merged :)10:32
opendevreviewDmitriy Rabotyagov proposed openstack/neutron-vpnaas master: Remove `restart-by-peer` from dpd actions  https://review.opendev.org/c/openstack/neutron-vpnaas/+/87832110:34
opendevreviewFelix Huettner proposed openstack/neutron master: ovn-l3 scheduler: calculate load of chassis per priority  https://review.opendev.org/c/openstack/neutron/+/89365311:04
opendevreviewFelix Huettner proposed openstack/neutron master: ovn-l3: reschedule lower priorities  https://review.opendev.org/c/openstack/neutron/+/89365411:04
opendevreviewFelix Huettner proposed openstack/neutron master: ovn-l3: reschedule priorities on new chassis  https://review.opendev.org/c/openstack/neutron/+/89365511:04
opendevreviewFelix Huettner proposed openstack/neutron master: ovn-l3 router scheduler: reproduce scheduling issue  https://review.opendev.org/c/openstack/neutron/+/89365611:04
opendevreviewFelix Huettner proposed openstack/neutron master: ovn-l3: implement caching for Scheduler  https://review.opendev.org/c/openstack/neutron/+/89365711:04
opendevreviewFelix Huettner proposed openstack/neutron master: ovn-l3: try to keep routers at current chassis  https://review.opendev.org/c/openstack/neutron/+/89365811:04
opendevreviewFelix Huettner proposed openstack/neutron master: ovn-l3: value the higher priorities when scheduling  https://review.opendev.org/c/openstack/neutron/+/89365911:04
opendevreviewMartin Kopec proposed openstack/neutron-tempest-plugin master: Fix network sorting in API tests  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/90585311:09
ralonsohrubasov, hello! I'm checking https://review.opendev.org/c/openstack/neutron/+/90512511:22
ralonsohalong with http://www.openvswitch.org//ovs-vswitchd.conf.db.5.pdf11:22
ralonsoh(I've reviewed this documentation several times)11:22
ralonsoh"For an access port, the port’s implicitly tagged VLAN"11:22
ralonsohI think we should also define tag=0 for the parent port, to accept only untagged traffic11:23
*** ravlew is now known as Guest1442311:33
opendevreviewFernando Royo proposed openstack/ovn-bgp-agent master: Fix OVN LB Delete events for NB driver  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/90578311:35
opendevreviewFernando Royo proposed openstack/ovn-bgp-agent master: Fix OVN LB Delete events for NB driver  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/90578311:55
rubasovralonsoh: 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
rubasovset tag=0.12:23
rubasovin my test environment the tpt keeps working if I set both vlan_mode=access and tag=0 (as it should)12:24
ralonsohrubasov, perfect12:36
ralonsohone quick question (because you implemented this plugin)12:36
rubasovshoot (however I was not really the implementor, but maybe I know)12:37
ralonsohcouldn't be possible to have one single port with mode=trunk and trunk=0,vlan1,vlan2,etc?12:37
ralonsohOVS can filter with one single port all needed VLANs12:37
ralonsohthat could avoid the creation of many ports in OVS12:37
rubasovthe vlan remapping between br-ints internal vlans and the user trunks segmentation-ids would be problematic12:38
rubasovthe usual ovs pattern to remap a vlan requires two bridges12:38
ralonsohthis could be done with the same rules we have12:38
ralonsohyes, with 2 bridges as is now12:38
ralonsohbut instead of having multiple patch ports between br-int and br-trunk12:39
ralonsohjust one12:39
rubasovI'm not saying the remapping would be impossible with pure openflow rules, but it would lead to a very complicated flow set I believe12:40
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM == WIP == Define the namespace for RPC metadata  https://review.opendev.org/c/openstack/neutron/+/90530912:40
ralonsohprobably yes, because you can't filter by inport12:41
rubasovyes, exactly12:41
ralonsohbut with multiple subports (100)12:41
ralonsohthere are a lot of problems with timeouts12:42
ralonsohthat could be cleaner and faster12:42
ralonsohin any case, I'll open a LP just to track this possible improvement12:42
rubasovthat's a kind of documented scaling limitation: https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling12:44
rubasovwhich can be tackled quite well by raising rpc_response_timeout12:44
ralonsohand we hit that several times in our internal CI12:44
ralonsohwith 100-200 subports12:44
rubasovespecially 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 default12:46
ralonsohyes but is still an issue to wait for 200 seconds for a VM to be ready12:46
rubasovyes, but isn't a large part of that wait on the server side? we can't optimize that away from the agent12:49
ralonsohthe server side is waiting for the plug events form the agent13:00
ralonsohif we plug one single port, that will be much faster13:00
ralonsohin any case, I'll try to do a POC, "just for fun"13:01
opendevreviewBence Romsics proposed openstack/neutron master: Set trunk parent port as access port in ovs to avoid loop  https://review.opendev.org/c/openstack/neutron/+/90512513:54
rubasov^ uploaded a new ps with tag=014:02
rubasovregarding 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 side14:04
ralonsohrubasov, and the subport.plug?14:04
ralonsohwhat I was proposing is something like this14:04
ralonsohTrunkParentPort.plug(br_int, tag=0)14:05
ralonsohby default Trunk will be tag=014:05
ralonsohSubPort.plug will call super() with tag=self.segmentation_id14:05
ralonsohright?14:05
ralonsohabout the optimizations: right but I don't know if the subport bindings is the time consuming part and not the OVS port creation14:07
ralonsohbut yes, port binding in the server could be very time consuming14:08
opendevreviewBence Romsics proposed openstack/neutron master: Set trunk parent port as access port in ovs to avoid loop  https://review.opendev.org/c/openstack/neutron/+/90512514:39
opendevreviewSahid Orentino Ferdjaoui proposed openstack/neutron master: dhcp: ensure that cleaning DHCP process for segment 0 happens first  https://review.opendev.org/c/openstack/neutron/+/90561714:40
opendevreviewTakashi Kajinami proposed openstack/tap-as-a-service master: Bump hacking  https://review.opendev.org/c/openstack/tap-as-a-service/+/90587814:45
opendevreviewSahid Orentino Ferdjaoui proposed openstack/neutron master: dhcp: ensure that cleaning DHCP process with one segment happens first  https://review.opendev.org/c/openstack/neutron/+/90561714:47
opendevreviewHervé Beraud proposed openstack/networking-sfc master: bump eventlet to latest version that support python 3.12  https://review.opendev.org/c/openstack/networking-sfc/+/90592315:11
opendevreviewHervé Beraud proposed openstack/neutron master: bump eventlet to latest version that support python 3.12  https://review.opendev.org/c/openstack/neutron/+/90592415:12
opendevreviewHervé 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/+/90592515:12
opendevreviewHervé Beraud proposed openstack/neutron-fwaas master: bump eventlet to latest version that support python 3.12  https://review.opendev.org/c/openstack/neutron-fwaas/+/90592615:13
opendevreviewHervé 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/+/90592715:15
opendevreviewHervé Beraud proposed openstack/os-ken master: bump eventlet to latest version that support python 3.12  https://review.opendev.org/c/openstack/os-ken/+/90592915:18
opendevreviewMiguel Lavalle proposed openstack/neutron master: Router flavors and service type for OVN  https://review.opendev.org/c/openstack/neutron/+/88398815:34
opendevreviewMerged openstack/neutron master: ovn-l3 scheduler: calculate load of chassis per priority  https://review.opendev.org/c/openstack/neutron/+/89365315:34
opendevreviewMerged openstack/neutron master: ovn-l3: reschedule lower priorities  https://review.opendev.org/c/openstack/neutron/+/89365415:34
mlavalleralonsoh, 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
ralonsohsure15:37
opendevreviewMiguel Lavalle proposed openstack/neutron master: [PoC][DNM] Enable HA for OVN router flavors  https://review.opendev.org/c/openstack/neutron/+/90151315:44
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM == WIP == Define the namespace for RPC metadata  https://review.opendev.org/c/openstack/neutron/+/90530915:51
opendevreviewHervé 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/+/90596815:54
tkajinamis taas now part of the official projects in neutron, right ? https://opendev.org/openstack/tap-as-a-service15:58
tkajinamI 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 repo15:59
opendevreviewMerged openstack/neutron-lib master: Bump hacking  https://review.opendev.org/c/openstack/neutron-lib/+/90571816:03
opendevreviewBence Romsics proposed openstack/neutron master: Set trunk parent port as access port in ovs to avoid loop  https://review.opendev.org/c/openstack/neutron/+/90512516:32
*** gthiemon1e is now known as gthiemonge16:41
opendevreviewMerged openstack/neutron-vpnaas master: Update python classifier with py3.10 & py3.11 in setup.cfg  https://review.opendev.org/c/openstack/neutron-vpnaas/+/90530217:02
haleybmnaser: 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 date17:20
opendevreviewMerged openstack/neutron master: [OVN] Update lsp host id when virtual parent moves  https://review.opendev.org/c/openstack/neutron/+/89688318:08
opendevreviewMerged openstack/neutron master: Make get_ports RPC method common for the DHCP and Metadata agent  https://review.opendev.org/c/openstack/neutron/+/90487218:35
noonedeadpunkhi 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
fricklernoonedeadpunk: for me, OVN + bgp dragent is working the same way it did with OVS. that's without using DVR though19:09
noonedeadpunkfrickler: so computes don't have access to provider networks?19:09
noonedeadpunk(directly)19:10
noonedeadpunkbut that's interesting19:10
noonedeadpunkI would never thought it will work for some reason19:11
fricklerwell we don't have actual provider networks, just a single public (=internet) network, and we explicitly don't want computes to be connected to that19:11
noonedeadpunkyeah, ok, so more or less same usecase I have19:11
fricklerit needed a bit of patching for n-d-r, but that should have been backported to at least zed or yoga I think19:11
noonedeadpunkok, awesome then19:12
noonedeadpunkthanks for the info!19:12
fricklerthere'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.html19:15
opendevreviewJakub Libosvar proposed openstack/ovn-bgp-agent master: Refactor ensure_routing_table_for_bridge  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/90579519:19
haleybralonsoh: 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 already19:50
opendevreviewMerged openstack/neutron master: Router flavors and service type for OVN  https://review.opendev.org/c/openstack/neutron/+/88398820:27
opendevreviewMiro 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/+/90590620:33
opendevreviewBrian Haley proposed openstack/neutron master: Remove string support in install_instructions  https://review.opendev.org/c/openstack/neutron/+/90575521:08
opendevreviewBrian Haley proposed openstack/neutron master: Fix keyword-arg-before-vararg warnings  https://review.opendev.org/c/openstack/neutron/+/90600621:09

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!