14:03:31 <lajoskatona> #startmeeting neutron_drivers
14:03:31 <opendevmeet> Meeting started Fri Mar  4 14:03:31 2022 UTC and is due to finish in 60 minutes.  The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:31 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:31 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:03:33 <lajoskatona> Hi,
14:03:35 <ralonsoh> hi
14:03:35 <mlavalle> o/
14:03:47 <trident> Hi
14:04:00 <amotoki> hi
14:04:04 <obondarev> hi
14:04:14 <gibi> o/
14:05:04 <lajoskatona> ok, let's start
14:05:12 <lajoskatona> we have one topic left from last week:
14:05:15 <lajoskatona> Gratuitous ARPs are not sent during master transition: (#link https://bugs.launchpad.net/neutron/+bug/1952907):
14:05:51 <lajoskatona> the link again without extra chars: #link https://bugs.launchpad.net/neutron/+bug/1952907
14:06:34 <ralonsoh> I'll start, if you don't mind
14:06:46 <ralonsoh> I took a look at proposal 1, https://github.com/acassen/keepalived/commit/b10bbfc2a2b216487cea5a586c55765275e41253
14:07:05 <ralonsoh> since keepalived 2.0.19, this is solved in the service itself
14:07:23 <lajoskatona> thanks
14:07:26 <ralonsoh> I would like to confirm that this was the initial problem to implement https://review.opendev.org/c/openstack/neutron/+/707406
14:07:29 <trident> Damian is unfortunately on vacation. I'll try to cover it from our side.
14:07:40 <lajoskatona> this is for this patch: https://review.opendev.org/c/openstack/neutron/+/712474
14:08:06 <lajoskatona> trident: thanks, I was looking for Damian to ping him
14:09:02 <trident> The more I have looked into it the more I am wondering if we can either revert (if we are okay to require keepalived > 2.0.19) or re-work https://review.opendev.org/c/openstack/neutron/+/707406 ...
14:10:19 <obondarev> are there any issues with keepalived upgrade?
14:10:39 <trident> To be honest for more reasons than only this issue. Mainly for mixing neutron into the process of failing over. Before neutron agents did actually not have to be at a fully working condition to in fact perform a successful fail over as everything was up, plugged and ready to roll as soon as the VRRP failed over.
14:11:04 <opendevreview> yatin proposed openstack/neutron master: [DNM] Check ovn ovs experimental  https://review.opendev.org/c/openstack/neutron/+/831220
14:12:31 <ralonsoh> I think obondarev was asking if using a keepalived newer version is a problem for the L3 agent
14:13:12 <mlavalle> newer meaning 2.0.19, right?
14:13:17 <ralonsoh> yes
14:13:23 <lajoskatona> exactly
14:14:05 <ralonsoh> btw, this is the version used now in our CI with ubuntu 20.04
14:14:09 <ralonsoh> 2022-03-03 17:38:20.185329 | controller | Unpacking keepalived (1:2.0.19-2ubuntu0.2) ...
14:15:14 <trident> Yeah, 2.0.19 comes with Ubuntu 20.04 and we have run it pretty extensively and had no issues related to that version.
14:16:03 <trident> So, from that point of view I think it would be okay to revert https://review.opendev.org/c/openstack/neutron/+/707406
14:16:18 <mlavalle> trident: "run it pretty extensively" after reverting the changes in https://review.opendev.org/c/openstack/neutron/+/707406?
14:16:47 <ralonsoh> if that is the case and in sake in simplicity, I would revert the change ^^ AND add a upgrade check with a warning
14:17:02 <mlavalle> in other words, do you know that after reverting it works fine with keepalived 2.0.19?
14:17:23 <ralonsoh> that should be tested manually I think
14:17:30 <trident> No, from the general point of view that 2.0.19 works fine with l3 agents.
14:17:33 <lajoskatona> ralonsoh: but that patch is in Neutrons since ussuri, so I suppose we can't backport the revert till that
14:17:39 <ralonsoh> lajoskatona, no no
14:17:44 <mlavalle> trident: thanks for the clarification
14:17:44 <ralonsoh> revert in master only
14:17:53 <lajoskatona> ralonsoh: +1
14:18:33 <ralonsoh> and I would ask slaweq, who created the initial bug, steps to reproduce it manually
14:19:12 <trident> The issue https://bugs.launchpad.net/neutron/+bug/1859832 that called for https://review.opendev.org/c/openstack/neutron/+/707406 has been a bit hard to verify that it is gone in 2.0.19 as it's pretty intermittent. So far I have not been able to re-produce that issue with the patch reverted, but that has been in small test environments.
14:19:51 <ralonsoh> trident, yes but at least we can try it manually with different versions of keepalived
14:20:57 <lajoskatona> trident: I can help with the upgrade check if you need assistance
14:21:09 <trident> Could probably put more time into it and force the IPv6 address flush to happen after the proper local_vlan_id is set for the port to really test it.
14:21:30 <trident> lajoskatona: That would be apreciated!
14:21:34 <mlavalle> so are we saying asking trident to do some more testing for the team?
14:23:14 <trident> Yeah, if we decide on a prefered path forward, we can put some time into testing that path out a bit and look into what's needed to get tha actual fix out.
14:24:05 <lajoskatona> trident: thanks, by fix you mean the revert and using keepalived 2.0.19?
14:24:23 <trident> Yes.
14:24:31 <lajoskatona> trident: I eman revert of https://review.opendev.org/c/openstack/neutron/+/707406
14:24:34 <lajoskatona> trident: ok
14:25:31 <mlavalle> so we revisit this next week? would that be enough time for you trident?
14:26:11 <trident> mlavalle: Sounds good!
14:26:45 <mlavalle> Thanks!
14:26:46 <lajoskatona> ok, than I think we agree on the way forward, and based on the results we check the next steps, is that ok
14:26:49 <lajoskatona> ?
14:26:57 <mlavalle> +1
14:26:57 <obondarev> +
14:26:58 <ralonsoh> +1
14:27:02 <trident> +1
14:27:03 <amotoki> +1
14:27:09 <lajoskatona> +1
14:27:12 <lajoskatona> Ok, thanks
14:27:18 <mlavalle> thank you trident for helping with this
14:27:31 <trident> Thanks!
14:27:33 <mlavalle> much appreciated
14:27:41 <lajoskatona> exactly, thanks for working on this and bringing it here
14:27:53 <lajoskatona> ok, next topic
14:28:14 <lajoskatona> #topic On Demand Agenda
14:28:29 <lajoskatona> (ralonsoh): https://bugs.launchpad.net/neutron/+bug/1962465. I want to discuss the scope of this bug and the possible fix.
14:28:36 <ralonsoh> thanks
14:28:39 <ralonsoh> patch: https://review.opendev.org/c/openstack/neutron/+/819147
14:29:25 <ralonsoh> the point here is that now we allow to have, in a single node, two external networks with overlaping CIDRs
14:29:31 <ralonsoh> or the same CIDR, for example
14:29:47 <lajoskatona> The comments were mostly realted to  the question if it can happen real env that 2 public nets has the same or overlapping subnet range
14:29:52 <ralonsoh> right
14:29:56 <lajoskatona> ralonsoh: thanks exactly
14:30:23 <ralonsoh> nothing should happen, having external networks doesn't imply those networks are connected to, for example, internet
14:30:35 <ralonsoh> "external" doesn't mean "internet connection"
14:30:54 <ralonsoh> external means to be connected to an upper network, outside openstack
14:30:57 <opendevreview> Balazs Gibizer proposed openstack/neutron master: Show port MAC from binding profile for PFs  https://review.opendev.org/c/openstack/neutron/+/829247
14:31:11 <obondarev> could we name that just provider networks?
14:31:28 <ralonsoh> perfect, provider networks
14:31:52 <mlavalle> lol
14:32:06 <ralonsoh> sorry, the patch is https://review.opendev.org/c/openstack/neutron/+/831238
14:32:09 <ralonsoh> my bad
14:32:26 <ralonsoh> if, in a future, we want to limit this, that's perfect
14:32:30 <ralonsoh> now it is not limited
14:32:46 <ralonsoh> and this patch will work now and in this possible future
14:33:08 <ralonsoh> (and, IMO, we should not force this artificial limitation)
14:33:43 <obondarev> +1 the fix does not seem so complex to limit the use case
14:33:57 <ralonsoh> right
14:34:49 <mlavalle> I'm ok with ralonsoh's proposal
14:35:06 <lajoskatona> yes, we can even document it somewhere to be clear
14:35:20 <ralonsoh> I'll add a reno and documentation
14:35:48 <mlavalle> no need to impose artificial limits when we don't know who might be taking advantage of the current freedom :-)
14:35:57 <lajoskatona> ralonsoh: thanks
14:36:19 <ralonsoh> thank you all
14:36:50 <mlavalle> amotoki: you good with this?
14:37:02 <amotoki> i am fine with this
14:37:07 <mlavalle> :-)
14:37:17 <lajoskatona> liuyulong has comments on the patch, but He is not here today
14:37:30 <lajoskatona> I am ok with this, so +1
14:37:40 <mlavalle> first rule in a fight is to shoup up
14:37:46 <mlavalle> show up
14:37:57 <mlavalle> if you don't, you loose for sure
14:38:51 <lajoskatona> mlavalle: true
14:39:33 <lajoskatona> ok, if no more comments, ralonsoh can continue the patch, and we can vote on it in the review
14:39:40 <mlavalle> +1
14:39:40 <ralonsoh> thanks
14:39:57 <lajoskatona> Next topic:
14:40:02 <lajoskatona> (mlavalle): Should we backport this: https://review.opendev.org/q/c9242f9a889f4d69653de4d21bec6060f549ee7b
14:40:25 <mlavalle> saw a comment in one of the patches asking whether we should backport this
14:40:36 <mlavalle> so decided to bring it up to the team
14:41:16 <ralonsoh> I don't think so: that changes the policies of stable projects. Those changes should be done only in master, adding release notes and documentation
14:42:00 <ralonsoh> in other words: bumping a minor version should imply a policy file change (if there is no an explicit bug)
14:42:09 <ralonsoh> should not*
14:42:53 <lajoskatona> ralonsoh: agree, this is an API change even if it is not explicit like an extension
14:43:13 <mlavalle> so we are saying that changing policy is akin to an outright api change
14:44:08 <amotoki> does it change the default and existing behavior? If not, it just bringes more granular polices to operators.
14:44:46 <amotoki> I think API change usually means behaviro changes for valid authorized users.
14:45:37 <ralonsoh> RBAC for quotas was something that existed in older releases
14:45:44 <ralonsoh> but wasn't used
14:46:14 <ralonsoh> if you created, by mistake, a RBAC register before this change, the behaviour will change too
14:46:23 <ralonsoh> (if I'm not wrong)
14:48:30 <amotoki> ah, that's the only case I think. it happens someone created such rules while they are not used.
14:49:23 <mlavalle> but if it was done by mistake, should we honor it?
14:49:52 <ralonsoh> mistake or not, the user is responsible
14:50:20 <ralonsoh> so if we backport this change, the policy behaviour will change only by user decissions/operations
14:50:47 <ralonsoh> if we accept this, then we can backport it
14:51:02 <mlavalle> I think it makes sense
14:51:13 <ralonsoh> (I would add a reno in the backports, please)
14:51:20 <mlavalle> yeap
14:51:36 <mlavalle> document it in case someone made that 'mistake'
14:51:44 <ralonsoh> right
14:51:48 <lajoskatona> it was in the original patch anyway
14:52:07 <mlavalle> yes, there is a reno there
14:52:20 <ralonsoh> perfect then
14:52:48 <lajoskatona> Ok, than with documentation we agree to backport his change to ussuri and train
14:52:52 <ralonsoh> +1
14:52:56 <lajoskatona> +1
14:52:58 <mlavalle> +1
14:53:00 <amotoki> +1
14:53:07 <obondarev> +1
14:53:13 <lajoskatona> Thanks
14:53:18 <mlavalle> thanks for the time :-)
14:53:49 <lajoskatona> We have few minutes gibi, ralonsoh do you think it is enough for https://review.opendev.org/c/openstack/neutron/+/829247 ?
14:53:49 <amotoki> reagrding "RBAC for quotas was something that existed in older releases", I looked through git logs and we never had a policy named "get_quota" before the commit backported.
14:53:58 <gibi> lajoskatona: let's try :)\
14:54:19 <ralonsoh> amotoki, not in the policies but in the API, we were able to create RBACs for quotas
14:54:29 <ralonsoh> gibi, lets go
14:54:40 <lajoskatona> ok, thanks
14:55:02 * mlavalle has a meeting in 5 minutes, might have to drop out if we go over time
14:55:03 <gibi> so we are talking about https://review.opendev.org/c/openstack/neutron/+/829247/3#message-42662fa9f1788ef4031c756abb9ee12ecc4761c7
14:55:12 <gibi> it was discussed before
14:55:28 <gibi> it is about to allow mac_address to be added to the binding:profile
14:55:35 <gibi> for direct-physical ports
14:55:55 <gibi> and to change neturon to show the MAC from the binding:profile for the direct-physical ports
14:56:12 <gibi> so the port.mac_address will show the MAC from the active binding:profile if any
14:56:31 <ralonsoh> the API (get/list ports) will should the binding:profile:mac (if exists), instead of port.mac
14:56:42 <gibi> yes
14:56:48 <ralonsoh> will show*
14:57:41 <gibi> but neutron will not overwrite the DB cell behind port.mac_address
14:57:56 <gibi> with the value from the binding:profile
14:58:06 <ralonsoh> I think this is a good solution for this problem (and, btw, maybe we'll find new cases for this with HW offload and smart NICs)
14:58:21 <mlavalle> are we concerned about the discrepancy?
14:58:41 <gibi> I have limited neutron knowledge so I'm not :)
14:58:48 <mlavalle> lol
14:59:00 <mlavalle> the bliss of ignorance
14:59:05 <gibi> yepp
14:59:10 <ralonsoh> the user (Nova in this case) who binds the port is reponsible of the port binding info
14:59:16 <gibi> yes
14:59:24 <mlavalle> ralonsoh: that's my opinion
14:59:43 <obondarev> maybe should consider support that in Port OVO
14:59:57 <ralonsoh> and MAC address is tightly related to the port binding: some NICs cannot change it
15:00:06 <amotoki> If other codes in neutron refers mac_address of ports, it may affect but perhaps it can be handled in the port object
15:00:08 <ralonsoh> obondarev, correct!
15:00:31 <ralonsoh> amotoki, right
15:00:46 <gibi> obondarev, ralonsoh: if you give me some pointers where to make the OVO change then I'm happy to do that in the current patch
15:00:54 <ralonsoh> gibi, I'll help on this
15:00:58 <gibi> cool
15:01:20 <gibi> btw is somebody is interested here is the nova side populating the bindig:profile https://review.opendev.org/c/openstack/nova/+/829248
15:01:34 <lajoskatona> so am I right that the db will not change just mirror the mac from binding:profile to OVO?
15:01:59 <ralonsoh> yes
15:02:01 <obondarev> +
15:02:05 <gibi> fine by me
15:02:07 <lajoskatona> ok, +1
15:02:09 <ralonsoh> (with the active binding)
15:02:14 <ralonsoh> +1
15:02:16 <mlavalle> +1
15:02:38 <amotoki> seems voting
15:02:39 <amotoki> +1
15:02:50 <lajoskatona> amotoki: thanks :-)
15:03:05 <lajoskatona> ok, so with this we finished all the topics for today
15:03:07 <gibi> I plugged a -W to the neutron patch
15:03:09 <ralonsoh> busy Friday!
15:03:14 <gibi> :)
15:03:15 <lajoskatona> Thanks everybody
15:03:17 <gibi> thanks!
15:03:18 <lajoskatona> Bye
15:03:22 <obondarev> o/
15:03:22 <ralonsoh> have a nice weekend
15:03:24 <amotoki> o/
15:03:25 <gibi> o/
15:03:26 <lajoskatona> #endmeeting