Friday, 2023-07-21

opendevreviewMiguel Lavalle proposed openstack/neutron master: [PoC][DNM] Test OVN L3 plugin with flavors  https://review.opendev.org/c/openstack/neutron/+/88774604:10
opendevreviewZhouHeng proposed openstack/neutron master: [ovn]Synchronize large-scale ACLs by committing multiple transactions  https://review.opendev.org/c/openstack/neutron/+/88522406:13
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Add NET_OWNER_MEMBER and NET_OWNER_READER policy rules  https://review.opendev.org/c/openstack/neutron/+/88915308:16
opendevreviewSlawek Kaplonski proposed openstack/neutron-lib master: Revert "Add "network" to the EXT_PARENT_RESOURCE_MAPPING"  https://review.opendev.org/c/openstack/neutron-lib/+/88902508:19
opendevreviewLucas Alvares Gomes proposed openstack/neutron master: [OVN] Retry retrieving LSP hosting information  https://review.opendev.org/c/openstack/neutron/+/88907308:53
opendevreviewMerged openstack/neutron-fwaas-dashboard master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/88635209:18
ralonsohfolks, the "test_get_datapath_id" is hitting the CI again11:08
ralonsohplease check https://review.opendev.org/c/openstack/neutron/+/88715011:08
ralonsohthanks!11:08
ralonsohslaweq, obondarev_ haleyb mlavalle ^11:08
obondarev_ralonsoh: so the test no longer does "set_db_attribute" and "dpid" gets into "self.br.get_datapath_id()" right away?11:19
ralonsohobondarev_, yes, is reading the defined datapath ID when the bridge is created11:20
obondarev_ack11:21
opendevreviewMerged openstack/neutron stable/2023.1: [OVN] Prevent binding a virtual type port  https://review.opendev.org/c/openstack/neutron/+/88775913:05
opendevreviewMerged openstack/neutron master: Initialize config in DietTestCase class  https://review.opendev.org/c/openstack/neutron/+/88794213:16
haleybralonsoh: i am curious why set_datapath_id() sets it in other_config but the test didn't, maybe a question for another day13:35
ralonsohhaleyb, because this is actually the place to update this value13:38
ralonsohhttps://mail.openvswitch.org/pipermail/ovs-discuss/2010-November/024500.html13:38
ralonsohyou can't modify the datapath directly but setting this other config value13:38
ralonsohto be honest, I don't know how that was working before...13:39
haleybmagic? i guess the test could have made the correct call, but the ID should be there at creation13:40
ralonsohin any case, we check that in other test13:41
ralonsohso I think is ok to check the bridge mac and the datapath ID13:41
ralonsohthat must match13:41
ralonsoh(if no other datapath has been configured)13:41
*** obondarev_ is now known as obondarev13:55
ralonsohPing list: ykarel, mlavalle, mtomaska, slawek, obondarev, tobias-urdin, lajoskatona, amotoki 14:01
mlavalleo/14:01
ralonsoh#startmeeting neutron_drivers14:01
opendevmeetMeeting started Fri Jul 21 14:01:15 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.14:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:01
opendevmeetThe meeting name has been set to 'neutron_drivers'14:01
felixhuettner[m]o/14:01
ralonsohhello all14:01
obondarevhi14:01
slaweqhi14:01
racostahi14:01
haleybhi14:01
ralonsohthis is the agenda of the meeting: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers14:01
ralonsohlet's give 30 seconds more14:02
ralonsohok, let's start14:02
ralonsohthe topic we have is14:02
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/202774214:03
ralonsoh[RFE] unmanaged dynamic router resources - OVN14:03
ralonsohracosta, please14:03
racostaFirst of all, thank you very much for taking the time to discuss this RFE.14:03
racostaThis is an opensource project with global impact, and I try to contribute as much as possible with the development of the solution and with experience/test results.14:03
racostaAs I mentioned in the RFE information and mailing list messages, I don't know any other option that allows learn and reinjecting routes at the SDN level (BGP with default gw/static routes does not do the same thing). https://lists.openstack.org/pipermail/openstack-discuss/2023-July/034377.html14:03
racostaWhy is it important? -> high availability14:03
racostaIn the proposed RFE, all the basic resources are created by OpenStack Neutron, including the tenant router. What do I need to add for interconnect to work? the LRP in the TS network.14:04
racostaThe LRP of the tenant's router connects with the TS (this transit switch behaves like a provider), as shown in the figure: https://drive.google.com/file/d/1lBP7MdvukRlQIE1yWU3K3jWGqnAGGQd3/view?usp=sharing14:04
racostaI tested an OVN interconnect integrated with 3 OpenStack installations and it worked very well. The TS is not known to Neutron and nothing happens to it. The point here is the "learned" Static Routes and LRPs (used to connect with the TS).14:04
racostaI understand the arguments about security that Rodolfo commented on the thread, but in this case, this LRP and these routes are created solely and exclusively in the tenant's network (having no overlap or problems with other tenant's subnets).14:04
racostaWhy should we make db_sync flexible? Even if other ways of managing TS are applied in Neutron, the static routes (which is the main point for the interconnect to work), would have to be made more flexible, and the tenant router would need to skip static routes learned from db_sync, for example. There are other points here about adding TS support as a network, scalability is the biggest one.14:04
racostaWhile it is possible to create the TS in Neutron itself (with a new RFE), this would mean having to add a new router in the tenant project and create static routes for that project. Don't you have problems with scaling on OpenStack? I mean, Neutron's networking backend have no infinite resources.14:05
racostaThe big problem with this approach is that with large scale deployments (thousands of tenants), the SDN can reach the limit and we will face timeout problems. The most classic I've faced with OpenStack Ussuri (which has lower limits) is "network-vif-plugged", caused by the OVN's delay in transitioning the Port events from chassis to the OVSDB Southbound and consequently Nova's ends up failing -  (even with configured network-vif-plugged 14:05
racostatimeouts of 300 seconds).14:05
racostawhat do you think about this RFE?14:06
ralonsohfirst of all, is everyone aware of the goal of this RFE? Do you have questions about it?14:07
slaweqI read today the thread on the ML14:08
slaweqIIUC it's about interconnecting 2 different OpenStack clusters14:08
slawequsing L314:08
slaweqis that correct?14:08
racostaYep, two or more OpenStack clusters.14:08
obondarevnot only OpenStack14:09
mlavallethat's my understanding as well14:09
ralonsohusing OVN IC, that creates an IC Transit Switch and requires OVN routers14:09
slaweqok14:09
mlavalleand yes, connect more that OpenStack14:09
obondarevalso connect openstack to smth else, right?14:09
slaweqand this reminded me old things which we had proposed long time ago:14:09
racostaYes, I tested it integrated with ovn-kube.14:09
slaweqOld spec https://specs.openstack.org/openstack/neutron-specs/specs/stein/neutron-interconnection.html14:09
slaweqold API-REF https://review.opendev.org/c/openstack/neutron-lib/+/626871 - was later removed with https://review.opendev.org/c/openstack/neutron-lib/+/626871 when we archived this stadium project,14:09
slaweqand stadium project  https://github.com/openstack-archive/neutron-interconnection/tree/1c5fbf56ff05f503745f7de7041f3e3e258d4f7314:10
slaweqdid You looked maybe at that spec and API? Maybe we could somehow base on that to implement it with ovn-ic now?14:10
felixhuettner[m]if i got it correctly the point of the RFE here is to not interfere with the resources created by/for OVN-IC inside the local ovn cluster14:10
mlavalleI have questions regarding ovn-kube: has this approach already been implemented with ovn-kube?14:10
felixhuettner[m]i did not understand that ic should be intergrated in neutron (or maybe just as a future topic)14:10
racostaI saw that slaweq but it wasn't continued. 14:11
slaweqracosta yes, it was proposed by guys from Orange but later they stopped working on it, at least u/s and there was nobody interested in that later14:11
racostaThat's the point Felix, the goal is for Neutron not to interfere with the ovn-ic.14:12
slaweqI'm just saying about it now, as maybe it would be useful - making it somehow part of neutron would mean that neutron will know about those resources so there may not be interfere problem anymore :)14:12
felixhuettner[m]that might also be an option (and would even make it more easily useable)14:13
racostamlavalle, to integrate with ovn-kube used this doc: https://github.com/kubeovn/kube-ovn/blob/v1.11.0/docs/cluster-interconnection.md14:13
felixhuettner[m]allthough i would only see the "usage" of this transit switch within neutron14:13
felixhuettner[m]not the management of it14:14
felixhuettner[m]otherwise we have one neutron ruling over other neutrons14:14
felixhuettner[m]which at least in our case is not what we want 14:14
ralonsohhow is that? each openstack cloud will create its resources (TS, routers, etc)14:15
felixhuettner[m]no the transit switch is own by ovn-interconnect (in a separate database)14:15
racostaYes Felix, remote LSP learned via ovn-ic should not be managed by Neutron.14:15
felixhuettner[m]and then "instanciated" in each individual ovn deployment14:15
felixhuettner[m]and i meant the transit switch within the ic databases14:15
ralonsohhold one, this IC belong to other OVN deployment?14:16
ralonsohthe IC database belongs to each cloud/OVN cluster14:16
slaweqI think I need to read more about ovn-ic because I never knew about this :) Because of that I may say totally stupid things regrarding this old spec - sorry for that14:16
ralonsoheach one has its own IC NB/IC SB database14:16
felixhuettner[m]no14:17
felixhuettner[m]there is one central IC NB+SB14:17
felixhuettner[m]and all OVN deployments have their individual normal NB+SB14:17
felixhuettner[m]and the ovn-ic daemon connects to the IC-NB+IC-SB and the normal NB+SB14:17
felixhuettner[m]and these IC NB+SB contain the information about the existence of this transit switch and who is connected there14:17
ralonsohright rigth, that's correct14:18
racostano worries slaweq, I had already seen it and even opened a thread in March mentioning this spec, but the case here is a little different.14:18
ralonsohso let's go to the NB resources case, what is the problem here14:18
slaweqracosta now I see :)14:18
felixhuettner[m]so the ovn-ic daemon will sync information from the IC-NB+IC-SB to the normal NB14:19
felixhuettner[m]this includes the transit switch (a logical switch)14:19
felixhuettner[m]the routes to other routes (logical router static routes)14:19
felixhuettner[m]and the ports of other devices on the transit switch (logical switch ports)14:19
racostalocal and the remote LSP's on the transit switch14:20
ralonsohand can these resources be tagged somehow from the IC controoler?14:20
ralonsohI mean the local NB resources14:20
felixhuettner[m]they are tagged iirc14:20
felixhuettner[m]let me check14:20
ralonsohso we have a way to recognize them, right14:20
felixhuettner[m]so logical switches have other_config:interconn-ts=***14:21
ralonsohand routers? 14:21
racostaIf they are not natively tagged, you can add an interconnect tag14:21
ralonsohNAT rules in OVN14:21
racostaThe routers are Neutron Native router... 14:22
ralonsohno14:22
ralonsohno14:22
felixhuettner[m]static routes have external_ids:ic-learned-route=xxx14:22
ralonsohyou said that you DON'T want to do resources from Neutron14:22
ralonsohfelixhuettner[m], ok14:22
ralonsohand the problem are the learned static routes, right?14:23
felixhuettner[m]and the logical switch ports14:23
ralonsohthat you don't have a way to correlate to the routers14:23
felixhuettner[m]and i think they have type=remote14:23
felixhuettner[m]but i'm not sure14:23
felixhuettner[m]but i guess we could exclude all resources with these tags from the sync 14:23
racostaOf course we can correlate ralonsoh, the LRP connected to the TS is linked with the Neutron router.14:24
ralonsohthat's the point, if you can correlate all of them, you can create these rules in the sync tool14:24
felixhuettner[m]+114:24
ralonsohracosta, ok, I've been trying to have a reply for this question for a whole week14:24
ralonsohlet me ask it again14:24
ralonsohyou are proposing a strategy here where the resources are NOT created in Neutron14:25
ralonsohright?14:25
racostaYes, interconnect LRP only (and learned static routes). Everything else is from Neutron DB and will be linked with TS via LRP14:26
racostaWe can define a tag to identify this LRP and handle it in the sync tool.14:28
ralonsohok, I have no idea what you are proposing, at all. I'm totally disoriented14:28
ralonsohI think you are mixing Neutron DB and OVN DB14:28
ralonsohin any case, at this point I'll stop writing and let other people to collaborate14:28
felixhuettner[m]aah, i missed that connection14:29
felixhuettner[m]so we where above at14:29
felixhuettner[m]there is a transit switch replicated to the normal northbound14:29
felixhuettner[m]and there is a normal router created by neutron in the standard way14:29
ralonsoh^ that's what I was expecting, finally14:30
ralonsohso this must be very clear in the spec 14:30
felixhuettner[m]and the needed LRP and LSP port to connect the router to the transit switch was still missing14:30
ralonsohwhat is created from the IC controller14:30
felixhuettner[m]and that is not created by ovn-ic 14:30
ralonsohand what manually in Neutron14:30
felixhuettner[m]and not created by neutron14:30
felixhuettner[m]and i think this causes all this confusion14:31
ralonsohyes14:31
ralonsohok, I'll stop now14:31
racostayep. TS - dynamic ovn managed. Logical_Router - Neutron managed. We need to connect this. 14:31
slaweqralonsoh speaking about spec - I think that this needs spec with well described problem statement and proposed solution (maybe with examples)14:31
mlavalleand a nice set of diagrams14:31
ralonsoh+114:31
slaweqmlavalle++14:31
haleybyes, i like pictures too14:32
felixhuettner[m]i agree as well, the amount of confusion it has created is quite large already :)14:32
obondarevso after all, what are neutron changes? Are there a lot?14:32
mlavalledepicting the components and who is responsible of managing each (i.e. OVN-IC vs Neutron)14:32
racostaI like too haleyb, I tried to put it but the openstack list blocks images... 14:33
obondarevmy impression was that the only change is to skip some resources (not delete) during db sync, is it correct?14:33
felixhuettner[m]yes (from my perspective)14:34
felixhuettner[m]just defining which is not easy 14:34
mlavallewhat is really positive about this proposal is that we have a feature in the underlying sdn backend that we are not leveraging in Neutron and we should explore how to do it, especially since other CMSs are already doing it14:34
felixhuettner[m]racosta: should we work together on this spec?14:34
felixhuettner[m](allthough i'll be on vaccation soonish)14:34
ralonsohjust a heads-up: any spec will be approved for the next release (C)14:35
racostaOf course Felix, that would be nice.14:35
haleybfrom reading the bug and listening here, i'm still not sure how this IC thing learns routes, etc - is it just sync or getting neutron events? how does it keep up to date? just something to make clear14:35
felixhuettner[m]it reads the routes from one clusters NB and puts it to the central IC-SB14:35
felixhuettner[m]then the other cluster takes it from the IC-SB and adds it to the clusters NB14:36
racostaYes, there is an ovn-ic daemon that monitors the NB DB and replicates to other elements of the interconnect domain (another OpenStack, for example) - but this route "learned" is limited to the scope of TS.14:37
haleybok, so it's watching OVN events after an initial sync14:38
felixhuettner[m]+114:39
racostaIn practice, a subnet behind an Openstack router can communicate to another subnet behind a router on another OpenStack (using L3).14:39
ralonsoh(I would expect a good documentation of how to create this IC between clusters)14:40
ralonsohany other question?14:40
ralonsohso let's vote for this RFE14:40
ralonsoh+1 (plus an spec)14:40
ralonsohfolks?14:41
slaweq+1 for RFE as I think that's great thing to have possibility to interconnect different clusters togethere14:41
mlavallelet's go for a spec14:41
mlavalle+114:42
ralonsohobondarev, ?14:42
mlavallethe good news is that we have time to be thorough with it14:42
obondarev+114:42
ralonsohso perfect, the RFE is approved. I'll comment that in the LP bug14:42
haleyb+114:42
ralonsohsorry14:42
ralonsohhaleyb, I missed you!14:42
ralonsohsorry14:42
haleybi'll go back to my corner :)14:42
ralonsohmy bad...14:43
ralonsohanything else you want to comment?14:43
haleybno, will wait for spec14:43
ralonsohthank you all for attending this meeting. Have a nice weekend14:43
ralonsoh(I'll be on PTO next week, just a heads-up)14:43
felixhuettner[m]thank you, have a nice weekend14:43
obondarevo/14:44
ralonsoh#endmeeting14:44
opendevmeetMeeting ended Fri Jul 21 14:44:02 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:44
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-07-21-14.01.html14:44
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-07-21-14.01.txt14:44
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-07-21-14.01.log.html14:44
mtomaskao/14:44
mlavalleo/14:44
ralonsohsee you14:44
racostaThank you again, have a nice weekend.14:44
slaweqo/14:44
haleybo/14:44
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Allow multiple VIPs per LB  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/88511115:15
opendevreviewMerged openstack/neutron master: [OVS] Check the datapath ID set by the creation method  https://review.opendev.org/c/openstack/neutron/+/88715016:52
*** melwitt is now known as jgwentworth18:26
opendevreviewMiguel Lavalle proposed openstack/neutron master: [PoC][DNM] Test OVN L3 plugin with flavors  https://review.opendev.org/c/openstack/neutron/+/88774620:03
*** haleyb is now known as haleyb_out21:54
opendevreviewMerged openstack/neutron master: Add sanity check for dnsmasq 2.86  https://review.opendev.org/c/openstack/neutron/+/88901523:26

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