14:00:11 <slaweq> #startmeeting neutron_drivers 14:00:11 <opendevmeet> Meeting started Fri Jul 23 14:00:11 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:11 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:11 <opendevmeet> The meeting name has been set to 'neutron_drivers' 14:00:14 <mlavalle> o/ 14:00:16 <slaweq> hi 14:00:33 <slaweq> thx mlavalle for taking care of the meeting 2 weeks ago :) 14:00:42 <mlavalle> O-) 14:00:53 <obondarev> hi 14:00:58 <ralonsoh> hi 14:01:18 <mlavalle> Unluckily we didn't have quorum large enough to take care or ralonsoh's rfe 14:01:25 <ramishra> hi 14:02:38 <slaweq> let's see if we will have quorum today 14:02:46 <slaweq> I know haleyb will not be here 14:02:51 <johnsom> o/ 14:02:58 <slaweq> but lets wait for njohnston, amotoki and yamamoto 14:04:03 <slaweq> mlavalle: btw. can You take a look at https://review.opendev.org/c/openstack/neutron-lib/+/747523/ when You will have some time? 14:04:05 <slaweq> thx in advance 14:04:07 <johnsom> slaweq I am joining today to chat about the quota RFE. I think there might be a bit of confusion on it. 14:04:11 <amotoki> hi, sorry for late 14:04:32 <mlavalle> slaweq: will do 14:04:52 <slaweq> johnsom: which quota rfe? 14:05:03 <njohnston> o/ 14:05:08 <ralonsoh> slaweq, https://bugs.launchpad.net/neutron/+bug/1936408 14:05:16 <johnsom> https://bugs.launchpad.net/neutron/+bug/1936408 14:05:18 <ralonsoh> but maybe we won't have time today 14:05:22 <johnsom> Yeah, that one. 14:05:44 <slaweq> johnsom: it's not on today's agenda 14:05:54 <slaweq> but lets talk about it when we will have some time at the end 14:05:56 <slaweq> ok? 14:06:02 <johnsom> Ok 14:06:44 <slaweq> ok, so lets talk about ralonsoh's rfe first 14:06:48 <slaweq> #topic RFEs 14:06:50 <slaweq> https://bugs.launchpad.net/neutron/+bug/1933517 14:06:57 <ralonsoh> thank you 14:07:01 <ralonsoh> the link for the spec 14:07:05 <ralonsoh> https://review.opendev.org/c/openstack/neutron-specs/+/799198 14:07:09 <ralonsoh> in a nuthsell 14:07:27 <ralonsoh> what we are trying is to create a port connected to br-int 14:07:42 <ralonsoh> and provide at the same time an ofport (in the interface) 14:08:04 <ralonsoh> when we have a VM, the tap port is created by libvirt 14:08:18 <ralonsoh> this is done at the end of the live-migration process 14:08:48 <ralonsoh> with this bridge in the middle 14:09:09 <ralonsoh> (same as with hybrid plug but with an OVS birdge) 14:09:25 <ralonsoh> the br-int port has an interface with an ofport inmediatly assigned 14:09:35 <ralonsoh> that triggers in OVN the port UP method 14:09:41 <ralonsoh> that means the port is provisioned 14:09:59 <ralonsoh> when the TAP port is connected (at the other side of this bridge) 14:10:14 <ralonsoh> the backend is ready to continue the communication 14:10:23 <ralonsoh> that's my summary 14:10:39 <opendevreview> Bence Romsics proposed openstack/neutron-lib master: multi-ext-gw: api-def and api-ref https://review.opendev.org/c/openstack/neutron-lib/+/802029 14:11:26 <ralonsoh> any question is welcome 14:11:51 <slaweq> I read the spec already and I'm ok with this. 14:12:02 <ralonsoh> thank you 14:12:06 <slaweq> I had some questions but it was already discussed in the spec 14:12:29 <slaweq> just to clarify - You will do that only for OVN backend, at least for now 14:12:35 <ralonsoh> right 14:12:41 <ralonsoh> it could be extended to OVS 14:12:43 <amotoki> does it apply to all VMs even without live migration? I think yes but it is just to clarify. 14:12:46 <ralonsoh> but the scope is OVN now 14:12:52 <ralonsoh> amotoki, yes, to any VM 14:12:52 <obondarev> could ml2-ovs benefit from such plugging as well? In live-migration case (to avoid packet loss) 14:12:56 <slaweq> and second thing - there will be no many changes in the Neutron really, most of the job will be done by os-vif, correct? 14:13:06 <obondarev> ah, I see reply already 14:13:10 <ralonsoh> obondarev, could be in a future, for sure 14:13:20 <ralonsoh> slaweq, there will be 14:13:35 <ralonsoh> because now we can send the event vif-plugged when the port is provisioned 14:13:50 <ralonsoh> that means, when Neutron server receives the port UP event from OVN 14:13:52 <slaweq> ahh, notification... :) 14:13:55 <ralonsoh> much better than now 14:14:29 <slaweq> so that will really fix those notifications for OVN backend finally, right? 14:14:55 <ralonsoh> yes, instead of sending the event when the port is updated (with migration_to in the vif details) 14:15:01 <ralonsoh> we send it at the right moment 14:15:06 <slaweq> ++ 14:15:59 <njohnston> +1 for me, all the questions I had when reading the spec have been covered already 14:16:31 <mlavalle> so, is it a question of fixing the timing of when the flows are created? 14:16:39 <ralonsoh> exactly 14:16:44 <ralonsoh> that's the key point here 14:17:00 <mlavalle> so we are ready when the vm is unpaused, right? 14:17:15 <ralonsoh> we don't now because the TAP port is not created in the dest host 14:17:23 <ralonsoh> it is when the VM is unpaused 14:17:31 <ralonsoh> and this is when the ofport is assigned 14:17:33 <ralonsoh> (too late) 14:17:45 <mlavalle> yeah, we just want to be ahead of all this 14:17:51 <ralonsoh> exactly 14:18:17 <amotoki> what happens for existing VMs? and what happens for live-migration for existing VMs? 14:18:29 <ralonsoh> bad yuyu 14:18:51 <ralonsoh> ok no 14:18:59 <ralonsoh> if you update the server 14:19:06 <ralonsoh> and os-vif 14:19:22 <ralonsoh> the intermediate bridge will be created in the new VM in the dest host 14:19:33 <ralonsoh> and, btw, this option will be configurable 14:19:47 <ralonsoh> there is no need for a VM running now to have this bridge 14:19:57 <ralonsoh> it is needed in the dest host 14:20:28 <amotoki> yeah, makes sense. 14:20:59 <amotoki> in addition, os-vif needs to handle both cases perperly when deleting ports 14:21:16 <ralonsoh> that's a corner case... 14:21:19 <ralonsoh> good catch 14:21:29 <ralonsoh> I'll add this info in the os-vif patch 14:21:52 <amotoki> no it is not a special corner case. it usually happens for existing VMs 14:22:09 <ralonsoh> if you update the nova compute and os-vif in this host 14:22:14 <ralonsoh> only in this acse 14:22:28 <ralonsoh> but we usually use live-migration to move VMs to updated servers 14:23:15 <amotoki> when we upgrade openstack only, we don't need to move VMs using live-migration 14:23:17 <slaweq> but we have multiple port bindings, so during live-migration wouldn't this binding be changed? 14:23:28 <slaweq> so on dest node it will already be plugged in the new way 14:23:44 <ralonsoh> the binding doesn't change 14:23:52 <ralonsoh> the VIF is the same 14:24:06 <slaweq> yes, but still You will have active and inactive binding for port 14:24:09 <slaweq> on different hosts 14:24:11 <ralonsoh> amotoki, in any case, this is something that must be considered in the os-vif patch for sure 14:24:30 <amotoki> ralonsoh: ack 14:24:31 <slaweq> so one can have new details conifgured, to be plugged in own bridge, no? 14:24:48 <ralonsoh> the binding information is the same 14:24:52 <slaweq> ok 14:24:55 <ralonsoh> this is an option in the os-vif library 14:25:07 <ralonsoh> not a hybrid-plug option in vif details 14:25:21 <ralonsoh> (as in OVS with hybrid-plug) 14:25:29 <ralonsoh> this should be transparent 14:25:39 <ralonsoh> (with the change in the vif-plugged event) 14:25:49 <ralonsoh> but even the OVN QoS is the same 14:27:16 <slaweq> I'm +1 for this RFE, as njohnston 14:28:47 <amotoki> +1 for the RFE. 14:28:58 <amotoki> my point on upgrade can be covered by the spec. I will add a comment to the spec. 14:29:10 <ralonsoh> amotoki, of course and thank you 14:29:11 <slaweq> thx amotoki 14:29:28 <slaweq> mlavalle: what about You? Any questions/comments? 14:29:39 <mlavalle> +1 from me as well 14:29:43 <slaweq> thx 14:29:45 <ralonsoh> thank you all 14:29:51 <slaweq> so I will mark that as approved 14:29:57 <slaweq> thx ralonsoh 14:30:07 <slaweq> let's move on to the next one 14:30:25 <slaweq> https://bugs.launchpad.net/neutron/+bug/1933222 14:30:43 <slaweq> this one was discussed on last meeting 14:31:26 <ralonsoh> for me the RFE is valid, I had some concerns in the implementation 14:31:37 <ralonsoh> but for sure we can address that in the patches 14:31:39 <slaweq> personally I would like to see some detailed diagram with details how this will be implemented 14:31:46 <ralonsoh> exactly 14:32:18 <slaweq> but in general, I'm ok with the idea if it would be optional extension to the OVS agent 14:34:36 <amotoki> same opinion. it is generally okay. Our previous discussion focused on clarifying the detail. the spec needs to clarify the detail. 14:34:54 <slaweq> amotoki: yes, I think that spec is for sure needed for that one 14:35:40 <mlavalle> +1 for clarifying during spec pahse 14:35:59 <slaweq> njohnston: any questions/comments on that one? 14:36:12 <amotoki> one question on testing. we have distributed version of dhcp and will have metadata. Do we want to enable them in DVR tests? 14:36:40 <ralonsoh> we'll need new jobs, right? 14:37:32 <amotoki> new jobs would work but I am just afraid having more jobs... 14:37:34 <njohnston> slaweq: I am a definite +1 on the idea, but diagrams and spec discussion is a definite must for a change like this 14:37:52 <slaweq> amotoki: I don't think we need that in the dvr job 14:38:04 <slaweq> IMO we can enabled those features in one of the existing ovs jobs 14:38:13 <slaweq> we have couple of them already 14:38:29 <amotoki> okay. thanks 14:38:58 <slaweq> but that's good point about testing :) 14:39:52 <slaweq> so I assume that we all agreed to mark that one as approved 14:39:58 <slaweq> and follow up in the spec now 14:40:09 <slaweq> I will comment on it after the meeting 14:40:25 <slaweq> now we have 3rd one: 14:40:27 <slaweq> https://bugs.launchpad.net/neutron/+bug/1935847 14:40:59 <ramishra> thanks slaweq 14:41:17 <slaweq> amotoki had some good comments there already 14:41:35 <slaweq> and also I think that obondarev's question is very interesting 14:41:45 <slaweq> I was also thinking about it yesterday while reading this rfe 14:42:27 <ramishra> ironic has something similar in-tree, I've not seen any req from other services/projects 14:42:28 <amotoki> obondarev's point is similar to my 2nd point in comment #4. 14:42:56 <slaweq> ramishra: if ironic have it and now neutron would have it - maybe it's worth to do it as part of oslo or something like that? 14:43:09 <obondarev> +1 14:43:55 <ramishra> So the intent is to make standalone neutron more usable for certain use-cases in near term 14:43:55 <amotoki> it is not specific to neutron, so you can use an existing basic-auth middleware or develop a new one for example under oslo or outside fo openstack. 14:44:26 <ramishra> we can probably think of having an implementation is oslo later that can be used by all projects 14:44:45 <amotoki> ramishra: did you consider using an exisitng middleware for basic auth instead of implementing it in neutron? 14:45:08 <amotoki> for example wsgi-basic-auth I mentioned in the comment. 14:45:12 <slaweq> ramishra: You said that ironic have it already, can't You just import and use it in neutron's pipeline in Your use case? 14:45:22 <slaweq> that would be fastest way to have it, no? 14:45:57 <ramishra> amotoki: I guess the one you mentioned does not support bcrypt hash for passwords 14:46:35 <amotoki> ramishra: okay but it does not mean we should have it in the neutron repo 14:46:52 <slaweq> I tend to agree with amotoki here :) 14:47:07 <ralonsoh> the idea of having it implement in oslo.middleware is interesting 14:47:17 <ralonsoh> ironic will use it too 14:47:18 <ramishra> IMO expecting standalone users to maintain a middleware separtely won't be big ask? 14:47:23 <amotoki> generaly speaking, we should avoid copying implementations. if ironic already has it and it can be re-used by otherr projects, we can consider oslo 14:48:03 <obondarev> that's what oslo is all about 14:48:53 <amotoki> ramishra: we already uses many libraries from outside of OpenStack, so "maintain a middleware separately" is not a big risk. 14:49:11 <ramishra> It would have been better if ironic would have proposed to oslo, but they did not in-tree 14:49:52 <ralonsoh> oslo people are nicer than us hehehe 14:49:58 <slaweq> ralonsoh: LOL 14:49:59 <ramishra> not sure if they proposed to oslo 14:49:59 <ralonsoh> if you present this idea next monday 14:50:04 <ramishra> and was rejected 14:50:06 <ralonsoh> the will accept if for sure 14:50:15 <ralonsoh> you can check next monday 14:50:19 <ralonsoh> I'll be there too 14:50:35 <ralonsoh> at 1500 UTC 14:50:39 <obondarev> I think ironic might thought they are the only OSt project needed it at that moment 14:51:04 <slaweq> obondarev: but now it will be at least 2 so things have changed :) 14:51:15 <obondarev> slaweq: right 14:51:41 <amotoki> based on your input, at least ironic and neutron need a middleware for basic-auth, so it is a good to have it in oslo. 14:51:43 <ramishra> OK, we can try that. But I thought for standalone services dependency external implementation or oslo should be less 14:51:54 <amotoki> perhaps cinder standalone may use it. 14:52:19 <obondarev> neutron already depends on oslo heavily anyway 14:52:25 <mlavalle> yeap 14:52:52 <amotoki> neutron standalone already depends on pyroute externally maintained (outside of OpenStack) :p 14:52:59 <slaweq> obondarev: exactly - if You install neutron You will have oslo.middleware installed 14:53:10 <amotoki> so I don't think one more dependency is not a matter.... 14:53:47 <slaweq> so I'm -1 for this rfe in Neutron, it should be probably part of oslo IMO, or completly external thing 14:53:58 <mlavalle> Agree 14:54:07 <ramishra> As it's non-invasive middleware, IMHO having in-tree is the best thing. But I take your point, if it's to be used by other services, better keep it in neutron 14:54:17 <amotoki> +1 as I already commented 14:54:33 <ramishra> *keep it oslo 14:54:36 <slaweq> ralonsoh: njohnston: any thoughts? 14:54:37 <mlavalle> amotoki: +1 to the -1, right? 14:54:44 <ralonsoh> +1 in oslo.middleware, -1 in Neutron 14:54:48 <amotoki> hehe. -1 14:54:52 <amotoki> -1 for neutorn 14:54:52 <slaweq> that's how I understood it too :) 14:54:57 <njohnston> agreed with the consensus 14:55:13 <slaweq> ok, so we are done with this one, I will comment on it after the meeting 14:55:18 <ramishra> ok thanks folks! 14:55:22 <slaweq> thx ramishra for discussing it with us 14:55:37 <slaweq> ok, let's quickly discuss johnsom's rfe 14:55:43 <slaweq> https://bugs.launchpad.net/neutron/+bug/1936408 14:55:59 <ralonsoh> yeah, this is mine 14:56:05 <johnsom> ha, not mine 14:56:24 <slaweq> ok, sorry 14:56:25 <johnsom> I just wanted to make sure it is clear, the octavia team is not asking for this change. 14:56:27 <ralonsoh> the point of this feature is to check the available resources when modifying the quota limits 14:56:37 <ralonsoh> of course, this API change will be configurable 14:56:57 <ralonsoh> the default behaviour will be the one we have now, do NOT check anything 14:57:26 <ralonsoh> the description is easy, the problem is the implementation (but this is out of scope here, I think) 14:57:28 <johnsom> It seemed there might be some confusion since this change was requested of octavia in addition to neutron, as we both implement the quota api in the same way. 14:57:41 <slaweq> ralonsoh: I think You told me some day that e.g. nova behaves in the way like You are proposing now 14:57:43 <slaweq> correct? 14:57:46 <ralonsoh> yes 14:57:59 <njohnston> I am wondering why this change is being requested - is this coming from the API working group to establish uniformity? 14:57:59 <slaweq> so it seems that there are 2 "fractions" in the OpenStack 14:58:06 <ralonsoh> but please, I'm NOT proposing any change in the current API 14:58:15 <ralonsoh> I'm proposing make it configurable 14:58:26 <ralonsoh> via plugin or a parameter in the CLI 14:58:31 <slaweq> maybe we should send email and discuss it with the wider audience? to make it maybe consistent across all projects 14:58:37 <ralonsoh> of course I'll do 14:59:32 <slaweq> ok, we are on the top of the hour now. I think we can thing about it and get back to it on next meeting 14:59:39 <njohnston> +1 14:59:43 <slaweq> btw. I will be on pto next week (again) 15:00:04 <slaweq> mlavalle: will You be able to chair the meeting? or should I cancel it and we will meet in 2 weeks? 15:00:13 <mlavalle> that's good. this way you will keep young and pretty for a long time 15:00:20 <ralonsoh> hehehe 15:00:23 <slaweq> mlavalle: LOL, sure :) 15:00:32 <mlavalle> slaweq: yeah, I can chair the meeting 15:00:42 <slaweq> mlavalle: ok, thx 15:01:06 <slaweq> I will send You an email about it later tonight 15:01:11 <slaweq> before I will leave 15:01:12 <mlavalle> cool 15:01:21 <slaweq> ok, thx for attending the meeting 15:01:21 <mlavalle> with a reminder, right? 15:01:27 <slaweq> have a great weekend 15:01:29 <slaweq> #endmeeting