14:00:47 <haleyb> #startmeeting neutron_drivers
14:00:47 <opendevmeet> Meeting 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:47 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:47 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:57 <haleyb> Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, amotoki, haleyb, ralonsoh
14:00:58 <mlavalle> \o
14:01:03 <lajoskatona> o/
14:01:06 <slaweq> o/
14:02:06 <haleyb> vprokofev: glad to see you could make it (again)
14:02:24 <haleyb> we can wait a minute for ralonsoh as he had added something as well
14:02:57 <vprokofev> Thanks. Though I have a feeling this is not happening (again).
14:03:07 <cbuggy> o/
14:04:42 <ralonsoh> hi
14:04:59 <ralonsoh> sorry, I was in a call
14:05:09 <haleyb> ralonsoh: hi, so that makes 5 drivers, we can get started
14:05:18 <haleyb> first topic is from vprokofev
14:05:22 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2083214
14:05:29 <haleyb> [RFE] control random-fully behavior on a per-FIP base
14:06:46 <vprokofev> i don't know if i need to say something so just ask if you have any questions
14:06:59 <haleyb> For some background, there was a bug related to this and we fixed it by adding a config option to control SNAT
14:07:05 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/854041
14:07:24 <vprokofev> yes, but as i mentioned before - it's global
14:07:29 <haleyb> vprokofev: sorry, i was slow, but if you want to explain the rfe a little that would be good
14:07:31 <vprokofev> you enable/disable it for the whole cloud
14:07:50 <lajoskatona> As I see this proposal is a good extension of the above cfg option (from https://review.opendev.org/c/openstack/neutron/+/854041 )
14:08:06 <vprokofev> this comes from a real use-case in a cloud i operate
14:08:24 <vprokofev> we have some customers who use overlay networks which use udp hole punching
14:08:31 <vprokofev> random-fully breaks it for them
14:08:41 <vprokofev> so we want to disable it for some specific IPs
14:09:02 <vprokofev> i pretty much wrote implementation of it already
14:09:09 <vprokofev> and din't want to carry private patch around
14:09:15 <vprokofev> also others can benefit from it
14:09:37 <lajoskatona> +1, thanks for proposing it here
14:09:52 <mlavalle> besides testing it in devstack, have you deployed it in production?
14:10:20 <vprokofev> not yet, it's pending change request approval. internal procedures, you know
14:10:35 <haleyb> what does OVN do in this case? is there any changes needed there?
14:11:00 <vprokofev> not that i'm aware of since we're using OVS
14:11:18 <ralonsoh> if we implement this API for FIP, that will have partial support
14:11:22 <mlavalle> I think it is ML2/OVS only
14:11:38 <slaweq> so does it mean that with your proposal config option which we have now for this will be not needed anymore?
14:12:29 <vprokofev> no, config option can still be used. my idea was to set default value to None so behavior is inherited from config option
14:12:49 <haleyb> mlavalle: right, i just didn't want to create another gap if OVN has some similar type option (i just don't know)
14:13:14 <ralonsoh> no no, if this is a new API for floating IPs, then we should not use a config option
14:13:28 <ralonsoh> we usually don't support API config driven options
14:13:30 <haleyb> ralonsoh: there is already a config option
14:13:34 <ralonsoh> I know
14:13:40 <slaweq> but 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 FIP
14:13:50 <ralonsoh> but this change wants to control each FIP individually
14:13:59 <ralonsoh> so that means a new API for FIPs
14:14:10 <ralonsoh> we can provide a default value=False, as is now
14:14:18 <slaweq> or maybe it could be done for router instead of the FIP and then all FIPs using this router would have it enabled or disabled
14:14:28 <lajoskatona> +1 and remove the cfg option
14:14:56 <lajoskatona> I mean +1 for API default=False, and remove cfg option
14:15:04 <vprokofev> the 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 validator
14:15:12 <slaweq> it 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 networks
14:15:47 <mlavalle> +1
14:15:51 <vprokofev> i 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't
14:15:56 <haleyb> use_random_fully defaults to True today
14:16:48 <lajoskatona> is this cfg option considered by OVN routers/FIPs?
14:17:03 <lajoskatona> or is this something that works only with iptables based implementation?
14:17:04 <haleyb> no only the iptables code currently
14:17:04 <ralonsoh> that doesn't apply to OVN, we don't have this in OVN
14:17:17 <lajoskatona> ack
14:18:09 <haleyb> ralonsoh: do we need to worry about OVN? is there even support for such a thing in core OVN?
14:18:25 <ralonsoh> I have no idea, to be honest
14:18:28 <ralonsoh> I would need to check it
14:18:45 <haleyb> ok, i didn't either
14:19:17 <haleyb> when vprokofev updates his could to OVN and things don't work the same he might be back here :)
14:19:24 <haleyb> s/could/cloud
14:19:40 <ralonsoh> first thing: document the parity gap with L3 agent
14:19:53 <haleyb> it's just something we need to document for now as you said
14:19:54 <ralonsoh> but let's focus on the L3 agent, not in OVN
14:22:25 <lajoskatona> +1
14:22:35 <haleyb> so do we need to discuss the point slaweq made about applying this to routers and fips?
14:23:06 <ralonsoh> maybe for now we can focus the goal to FIPs
14:23:17 <ralonsoh> we can extend that to routers in a follow-up implementation
14:23:30 <slaweq> ++
14:23:33 <mlavalle> +1
14:23:38 <haleyb> ok, so let's vote on this how it is described - applying to FIPs
14:23:43 <haleyb> +1 from me as well
14:23:54 <mlavalle> +1
14:24:03 <ralonsoh> +1 to this RFE, I would like to see a spec
14:24:06 <slaweq> +1
14:24:22 <lajoskatona> +1
14:24:43 <haleyb> ok, great, we have consensus
14:25:17 <haleyb> vprokofev: can you write-ip a spec on this? there is a neutron-specs repo
14:25:38 <haleyb> i need to double-check it has an epoxy subdir
14:26:10 <vprokofev> sure. never wriote one before, so it may require some proof-reading
14:26:48 <mlavalle> we will provide plenty of help with that
14:26:49 <ralonsoh> some examples https://review.opendev.org/q/project:openstack/neutron-specs
14:27:00 <ralonsoh> but you can ping us here
14:27:42 <vprokofev> thank, i'll write up one next week then
14:28:23 <haleyb> great, thanks, i'll create a 2025.1 folder
14:28:31 <mlavalle> thanks for your proposal!
14:28:55 <haleyb> ralonsoh: you had the next item on the agenda
14:29:37 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2083527
14:30:00 <ralonsoh> the first topic: To be able to nest two external networks, as explained in the LP bug
14:30:11 <noonedeadpunk> o/
14:30:16 <ralonsoh> this is something we don't test right now and I don't know if that is supported
14:30:45 <ralonsoh> this is: a network connected to a router, this router to a GW network, this network to a router and another GW network
14:30:57 <noonedeadpunk> so frankly - I haven't tested access to A-net from public (real external one)
14:31:03 <ralonsoh> this is a bit different to the nested routing scenario
14:31:12 <opendevreview> Takashi Kajinami proposed openstack/neutron master: Replace deprecated is_advsvc  https://review.opendev.org/c/openstack/neutron/+/931574
14:31:40 <noonedeadpunk> but the problem is that FIP did not work at all between middle and lower network
14:31:48 <noonedeadpunk> (while I'd expect it to)
14:32:30 <ralonsoh> because we expect a FIP to have communication thought a GW IP, outside OpenStack
14:32:41 <ralonsoh> but you are redirecting this traffic to another router
14:33:21 <haleyb> noonedeadpunk: stupid question, but had you tried with Ales' latest patch? it just merged to OVN last week
14:33:23 <noonedeadpunk> um, not really. so step 11 and 12 explain from where what I test
14:33:52 <noonedeadpunk> to OVN-OVN?
14:34:04 <noonedeadpunk> I did not build OVN from sources, no
14:34:19 <noonedeadpunk> and also https://review.opendev.org/c/openstack/neutron/+/931495 covers the usecase described
14:34:50 <haleyb> i just know there was an edge case with FIPs that the patch fixed i believe, so we don't chase our tails
14:35:31 <haleyb> but it's maybe orthagonal to your ask in the bug
14:37:01 <ralonsoh> about 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 SNAT
14:37:18 <ralonsoh> so I'm going to open a bug for this a link this patch too
14:37:42 <ralonsoh> (this case is for one router only, connected to a tunnelled GW network)
14:38:22 <haleyb> i 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 did
14:38:38 <haleyb> and snat to FIP
14:38:45 <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 FIP
14:38:52 <noonedeadpunk> so I'm not passing down 2 routers
14:40:20 <noonedeadpunk> and as router is binded to chassiss... And FIP NAT still to the router external port - things do not work
14:40:58 <ralonsoh> yes, this is why this bug should change the scope and the description
14:41:03 <noonedeadpunk> haleyb: it's good to know that OVN patch did cover that :)
14:41:14 <ralonsoh> I think there is too much noise in the testing procedure
14:41:35 <ralonsoh> if that is going to be tested with traffic through on router
14:41:40 <noonedeadpunk> Well, I first described what I feel is off, and only then realized what actually is wrong
14:42:01 <noonedeadpunk> so description is indeed generic
14:42:52 <ralonsoh> ok, so in shake of documentation for next developers, I would change the description and I would keep apart the nested routing
14:42:59 <ralonsoh> this is a red herring there
14:43:16 <noonedeadpunk> ok, yeah, will edit it
14:43:34 * noonedeadpunk still needs to invest in unit/functional test coverage
14:43:39 <ralonsoh> thanks a lot, I'll review the patch on monday, I think it makes sense and this is indeed a bug
14:43:59 <ralonsoh> (nothing else from me, thanks!)
14:44:13 <lajoskatona> this patch: https://review.opendev.org/c/openstack/neutron/+/931495 ?
14:44:21 <ralonsoh> yes
14:44:31 <haleyb> so more a bug than rfe
14:44:43 <ralonsoh> yes
14:45:48 <noonedeadpunk> but if you see something obviously wrong with the approach - please comment
14:46:00 <ralonsoh> sure, in the reviews
14:46:05 <noonedeadpunk> As I personally don't very much like string comparison of True...
14:46:16 <noonedeadpunk> but I saw that being used elsewhere in code...
14:46:24 <haleyb> ok. did we have any other rfes/bugs to discuss?
14:46:34 <ralonsoh> no thanks
14:46:44 <haleyb> if not i'll close this as i have a conflict i'm late for
14:47:14 <noonedeadpunk> thanks folks
14:47:15 <haleyb> thanks for attending everyone and have a good weekend
14:47:18 <haleyb> #endmeeting