Friday, 2024-10-11

opendevreviewRodolfo Alonso proposed openstack/neutron master: Optimize the SG rule retrieval  https://review.opendev.org/c/openstack/neutron/+/93204105:52
opendevreviewRodolfo Alonso proposed openstack/neutron master: Optimize the SG rule retrieval  https://review.opendev.org/c/openstack/neutron/+/93204105:53
opendevreviewRodolfo Alonso proposed openstack/neutron master: ``_make_security_group_rule_dict`` only accepts SG rule OVO  https://review.opendev.org/c/openstack/neutron/+/93216205:56
opendevreviewRodolfo Alonso proposed openstack/neutron master: Optimize the SG rule retrieval  https://review.opendev.org/c/openstack/neutron/+/93204106:00
opendevreviewRodolfo Alonso proposed openstack/neutron master: Optimize the SG rule retrieval  https://review.opendev.org/c/openstack/neutron/+/93204106:10
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM - "security_group_rules" is not a SG selectable field  https://review.opendev.org/c/openstack/neutron/+/93216306:10
opendevreviewRodolfo Alonso proposed openstack/neutron master: Replace ``greenthread.sleep`` with ``time.sleep``  https://review.opendev.org/c/openstack/neutron/+/93125108:17
opendevreviewliuyulong proposed openstack/neutron master: Add basical functionalities for metadata path extension  https://review.opendev.org/c/openstack/neutron/+/88153508:44
opendevreviewliuyulong proposed openstack/neutron master: Add metadata path extension openflows  https://review.opendev.org/c/openstack/neutron/+/88809708:44
opendevreviewliuyulong proposed openstack/neutron master: Fullstack case for metadata path  https://review.opendev.org/c/openstack/neutron/+/88809808:44
opendevreviewliuyulong proposed openstack/neutron master: Add devstack plugin to enable ovs metadata_path  https://review.opendev.org/c/openstack/neutron/+/92858608:44
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Add Health monitor sync logic  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/93128808:46
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Add sync floating IP support  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/92903909:44
opendevreviewRodolfo Alonso proposed openstack/neutron master: Optimize the SG rule retrieval  https://review.opendev.org/c/openstack/neutron/+/93204110:00
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM - "security_group_rules" is not a SG selectable field  https://review.opendev.org/c/openstack/neutron/+/93216310:00
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Add sync floating IP support  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/92903912:01
opendevreviewMerged openstack/neutron master: Do not dispose local_vlan_hints  https://review.opendev.org/c/openstack/neutron/+/88033412:35
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Add Health monitor sync logic  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/93128812:40
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Add sync floating IP support  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/92903912:40
ralonsohhaleyb_, hello! Give me today to add the eventlet stuff into the etherpad of the PTG12:45
*** ykarel_ is now known as ykarel13:04
*** haleyb_ is now known as haleyb13:07
haleybralonsoh: sure, i need to add things myself too13:08
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Add Health monitor sync logic  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/93128813:13
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Add sync floating IP support  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/92903913:13
opendevreviewRodolfo Alonso proposed openstack/neutron master: Optimize the SG rule retrieval  https://review.opendev.org/c/openstack/neutron/+/93204113:35
haleyb#startmeeting neutron_drivers14:00
opendevmeetMeeting started Fri Oct 11 14:00:47 2024 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'neutron_drivers'14:00
haleybPing list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, amotoki, haleyb, ralonsoh14:00
mlavalle\o14:00
lajoskatonao/14:01
slaweqo/14:01
haleybvprokofev: glad to see you could make it (again)14:02
haleybwe can wait a minute for ralonsoh as he had added something as well14:02
vprokofevThanks. Though I have a feeling this is not happening (again).14:02
cbuggyo/14:03
ralonsohhi14:04
ralonsohsorry, I was in a call14:04
haleybralonsoh: hi, so that makes 5 drivers, we can get started14:05
haleybfirst topic is from vprokofev 14:05
haleyb#link https://bugs.launchpad.net/neutron/+bug/208321414:05
haleyb[RFE] control random-fully behavior on a per-FIP base14:05
vprokofevi don't know if i need to say something so just ask if you have any questions14:06
haleybFor some background, there was a bug related to this and we fixed it by adding a config option to control SNAT14:06
haleyb#link https://review.opendev.org/c/openstack/neutron/+/85404114:07
vprokofevyes, but as i mentioned before - it's global14:07
haleybvprokofev: sorry, i was slow, but if you want to explain the rfe a little that would be good14:07
vprokofevyou enable/disable it for the whole cloud14:07
lajoskatonaAs I see this proposal is a good extension of the above cfg option (from https://review.opendev.org/c/openstack/neutron/+/854041 )14:07
vprokofevthis comes from a real use-case in a cloud i operate14:08
vprokofevwe have some customers who use overlay networks which use udp hole punching14:08
vprokofevrandom-fully breaks it for them14:08
vprokofevso we want to disable it for some specific IPs14:08
vprokofevi pretty much wrote implementation of it already14:09
vprokofevand din't want to carry private patch around14:09
vprokofevalso others can benefit from it14:09
lajoskatona+1, thanks for proposing it here14:09
mlavallebesides testing it in devstack, have you deployed it in production?14:09
vprokofevnot yet, it's pending change request approval. internal procedures, you know14:10
haleybwhat does OVN do in this case? is there any changes needed there?14:10
vprokofevnot that i'm aware of since we're using OVS14:11
ralonsohif we implement this API for FIP, that will have partial support14:11
mlavalleI think it is ML2/OVS only14:11
slaweqso does it mean that with your proposal config option which we have now for this will be not needed anymore?14:11
vprokofevno, config option can still be used. my idea was to set default value to None so behavior is inherited from config option14:12
haleybmlavalle: right, i just didn't want to create another gap if OVN has some similar type option (i just don't know)14:12
ralonsohno no, if this is a new API for floating IPs, then we should not use a config option14:13
ralonsohwe usually don't support API config driven options14:13
haleybralonsoh: there is already a config option14:13
ralonsohI know14:13
slaweqbut do we really need that option? I would rather deprecate and remove it, and for the API change, choose some default value which could be then overwritten for each FIP14:13
ralonsohbut this change wants to control each FIP individually14:13
ralonsohso that means a new API for FIPs14:13
ralonsohwe can provide a default value=False, as is now14:14
slaweqor maybe it could be done for router instead of the FIP and then all FIPs using this router would have it enabled or disabled14:14
lajoskatona+1 and remove the cfg option14:14
lajoskatonaI mean +1 for API default=False, and remove cfg option14:14
vprokofevthe way i implemented it doesn't break existing setups in any way. it does complicates things a bit since it requires a new validator of type "boolean_or_none" which did not exist before. removing config option means there's no need for a new validator14:15
slaweqit could be even added to both: router and fip resources and inherited by fips if not set for them directly, like we have for QoS policies for ports and networks14:15
mlavalle+114:15
vprokofevi did not consider enabling it on a per-router base since we needed some IPs in a project to use random-fully and some don't14:15
haleybuse_random_fully defaults to True today14:15
lajoskatonais this cfg option considered by OVN routers/FIPs?14:16
lajoskatonaor is this something that works only with iptables based implementation?14:17
haleybno only the iptables code currently14:17
ralonsohthat doesn't apply to OVN, we don't have this in OVN14:17
lajoskatonaack14:17
haleybralonsoh: do we need to worry about OVN? is there even support for such a thing in core OVN?14:18
ralonsohI have no idea, to be honest14:18
ralonsohI would need to check it14:18
haleybok, i didn't either14:18
haleybwhen vprokofev updates his could to OVN and things don't work the same he might be back here :)14:19
haleybs/could/cloud14:19
ralonsohfirst thing: document the parity gap with L3 agent14:19
haleybit's just something we need to document for now as you said14:19
ralonsohbut let's focus on the L3 agent, not in OVN14:19
lajoskatona+114:22
haleybso do we need to discuss the point slaweq made about applying this to routers and fips?14:22
ralonsohmaybe for now we can focus the goal to FIPs14:23
ralonsohwe can extend that to routers in a follow-up implementation14:23
slaweq++14:23
mlavalle+114:23
haleybok, so let's vote on this how it is described - applying to FIPs14:23
haleyb+1 from me as well14:23
mlavalle+114:23
ralonsoh+1 to this RFE, I would like to see a spec14:24
slaweq+114:24
lajoskatona+114:24
haleybok, great, we have consensus14:24
haleybvprokofev: can you write-ip a spec on this? there is a neutron-specs repo14:25
haleybi need to double-check it has an epoxy subdir14:25
vprokofevsure. never wriote one before, so it may require some proof-reading14:26
mlavallewe will provide plenty of help with that14:26
ralonsohsome examples https://review.opendev.org/q/project:openstack/neutron-specs14:26
ralonsohbut you can ping us here 14:27
vprokofevthank, i'll write up one next week then14:27
haleybgreat, thanks, i'll create a 2025.1 folder14:28
mlavallethanks for your proposal!14:28
haleybralonsoh: you had the next item on the agenda14:28
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/208352714:29
ralonsohthe first topic: To be able to nest two external networks, as explained in the LP bug14:30
noonedeadpunko/14:30
ralonsohthis is something we don't test right now and I don't know if that is supported14:30
ralonsohthis is: a network connected to a router, this router to a GW network, this network to a router and another GW network14:30
noonedeadpunkso frankly - I haven't tested access to A-net from public (real external one)14:30
ralonsohthis is a bit different to the nested routing scenario14:31
opendevreviewTakashi Kajinami proposed openstack/neutron master: Replace deprecated is_advsvc  https://review.opendev.org/c/openstack/neutron/+/93157414:31
noonedeadpunkbut the problem is that FIP did not work at all between middle and lower network 14:31
noonedeadpunk(while I'd expect it to)14:31
ralonsohbecause we expect a FIP to have communication thought a GW IP, outside OpenStack14:32
ralonsohbut you are redirecting this traffic to another router14:32
haleybnoonedeadpunk: stupid question, but had you tried with Ales' latest patch? it just merged to OVN last week14:33
noonedeadpunkum, not really. so step 11 and 12 explain from where what I test14:33
noonedeadpunkto OVN-OVN?14:33
noonedeadpunkI did not build OVN from sources, no14:34
noonedeadpunkand also https://review.opendev.org/c/openstack/neutron/+/931495 covers the usecase described14:34
haleybi just know there was an edge case with FIPs that the patch fixed i believe, so we don't chase our tails14:34
haleybbut it's maybe orthagonal to your ask in the bug14:35
ralonsohabout this patch, that is related to the second topic: this is fixing the scenario implemented in https://review.opendev.org/c/openstack/neutron/+/909194. I never tested it with FIPs, only SNAT14:37
ralonsohso I'm going to open a bug for this a link this patch too14:37
ralonsoh(this case is for one router only, connected to a tunnelled GW network)14:37
haleybi had tried the "nested" patch with FIP to FIP, but with the core OVN patch as well, which seemed to work, without i don't think it did14:38
haleyband snat to FIP14:38
noonedeadpunk> "so step 11 and 12 explain from where what I test" - So eventually what I'm testing is a VM on "fake-external" geneve network trying to access a "layered" VM on geneve through FIP14:38
noonedeadpunkso I'm not passing down 2 routers14:38
noonedeadpunkand as router is binded to chassiss... And FIP NAT still to the router external port - things do not work14:40
ralonsohyes, this is why this bug should change the scope and the description14:40
noonedeadpunkhaleyb: it's good to know that OVN patch did cover that :)14:41
ralonsohI think there is too much noise in the testing procedure14:41
ralonsohif that is going to be tested with traffic through on router14:41
noonedeadpunkWell, I first described what I feel is off, and only then realized what actually is wrong14:41
noonedeadpunkso description is indeed generic14:42
ralonsohok, so in shake of documentation for next developers, I would change the description and I would keep apart the nested routing14:42
ralonsohthis is a red herring there14:42
noonedeadpunkok, yeah, will edit it14:43
* noonedeadpunk still needs to invest in unit/functional test coverage14:43
ralonsohthanks a lot, I'll review the patch on monday, I think it makes sense and this is indeed a bug14:43
ralonsoh(nothing else from me, thanks!)14:43
lajoskatonathis patch: https://review.opendev.org/c/openstack/neutron/+/931495 ?14:44
ralonsohyes14:44
haleybso more a bug than rfe14:44
ralonsohyes14:44
noonedeadpunkbut if you see something obviously wrong with the approach - please comment 14:45
ralonsohsure, in the reviews14:46
noonedeadpunkAs I personally don't very much like string comparison of True...14:46
noonedeadpunkbut I saw that being used elsewhere in code...14:46
haleybok. did we have any other rfes/bugs to discuss?14:46
ralonsohno thanks14:46
haleybif not i'll close this as i have a conflict i'm late for14:46
noonedeadpunkthanks folks14:47
haleybthanks for attending everyone and have a good weekend14:47
haleyb#endmeeting14:47
opendevmeetMeeting ended Fri Oct 11 14:47:18 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:47
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-10-11-14.00.html14:47
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-10-11-14.00.txt14:47
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-10-11-14.00.log.html14:47
mlavalle\o14:47
ralonsohbye, have a nice weekend14:47
lajoskatonao/14:47
slaweqo/14:47
vprokofevthank you for your time!14:47
slaweqhave a great weekend all!!!14:47
ralonsohfolks, if you have some minutes: https://review.opendev.org/c/openstack/neutron/+/932041 (the failing tests are now passing)14:50
ralonsohif merged, I'll backport it14:50
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Use 'port-trusted-vif' api extension definition from neutron-lib  https://review.opendev.org/c/openstack/neutron/+/93218114:51
opendevreviewBrian Haley proposed openstack/neutron-specs master: Spec folder for 2025.1 cycle  https://review.opendev.org/c/openstack/neutron-specs/+/93218214:51
opendevreviewMerged openstack/neutron-specs master: Spec folder for 2025.1 cycle  https://review.opendev.org/c/openstack/neutron-specs/+/93218215:04
opendevreviewTakashi Kajinami proposed openstack/python-neutronclient master: Drop unused tempest from test requirements  https://review.opendev.org/c/openstack/python-neutronclient/+/93218715:06
opendevreviewRodolfo Alonso proposed openstack/neutron master: "security_group_rules" is not a SG selectable field  https://review.opendev.org/c/openstack/neutron/+/93216315:12
opendevreviewRodolfo Alonso proposed openstack/neutron-tempest-plugin master: [WSGI] Move all OVN jobs to use WSGI API module  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/93074315:14
opendevreviewStephen Finucane proposed openstack/neutron master: zuul: Explicitly set NEUTRON_DEPLOY_MOD_WSGI  https://review.opendev.org/c/openstack/neutron/+/93218915:14
ralonsohhaleyb, https://etherpad.opendev.org/p/oct2024-ptg-neutron. I've added the documentation for the eventlet deprecation15:26
ralonsohI'll also send an update in the mail chain stated by Herve15:26
ralonsoh(but later, I need to leave now)15:26
haleybralonsoh: ack, thanks15:29
opendevreviewMerged openstack/neutron master: Remove the sleep calls in the ``create_or_update_agent`` method  https://review.opendev.org/c/openstack/neutron/+/93124917:27
*** haleyb is now known as haleyb|out19:13
opendevreviewMerged openstack/neutron master: Add special treatment for 'any' in SG rule API  https://review.opendev.org/c/openstack/neutron/+/92649823:06

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