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