14:00:23 <slaweq> #startmeeting neutron_drivers
14:00:24 <openstack> Meeting started Fri Jun 19 14:00:23 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:27 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:30 <slaweq> welcome :)
14:00:32 <haleyb> hi
14:00:34 <lajoskatona> o/
14:00:35 <TomStappaerts> hi
14:00:39 <mlavalle> o/
14:01:51 <slaweq> lets wait few more minutes for njohnston_ and amotoki
14:02:00 <slaweq> as yamamoto will not be able to join today
14:02:08 <ralonsoh> hi
14:05:31 <slaweq> ok, there is 3 out of 6 team members already so I think we can start
14:05:52 <slaweq> as I said in email yesterday, I want to start with on demand agenda today
14:06:04 <slaweq> and later continue with RFEs
14:06:12 <slaweq> #topic On Demand Agenda
14:06:19 <slaweq> ralonsoh: Your topic here is first
14:06:28 <ralonsoh> thanks
14:06:37 <ralonsoh> in a nutshell
14:06:53 <ralonsoh> I would like to use the QoS API to add a new rule type
14:06:57 <njohnston_> o/
14:06:58 <ralonsoh> numa affinity
14:07:15 <ralonsoh> that means a port will be spawned only in a specific numa node
14:07:33 <ralonsoh> about yamamoto's question
14:07:34 <ralonsoh> "is this just about having a way to pass necessary info to nova?"
14:07:38 <ralonsoh> yes, exactly
14:07:52 <ralonsoh> you can create a port, with a qos and this new rule
14:08:09 <ralonsoh> and nova will take this info to spawn the vm and the port in this numa node
14:08:24 <ralonsoh> my question is: can we use this existing API?
14:08:26 <ralonsoh> thanks
14:09:24 <ralonsoh> (if you need a spec and a BP, I'll be glad to write them)
14:10:01 <slaweq> about spec, I think we will need that to describe API changes there
14:10:04 <mlavalle> what is the reasoning of association "numa affinity" to "qos"?
14:10:16 <mlavalle> associating^^^
14:10:18 <ralonsoh> good question
14:10:19 <lajoskatona> +1
14:10:21 <slaweq> what is the alternative to qos API for that?
14:10:54 <mlavalle> in priciple, it seems we are stretching the concept of qos...
14:11:05 <ralonsoh> I proposed qos because with this numa association, we are improving the possible throughput of those nics
14:11:10 <ralonsoh> I know...
14:11:15 <ralonsoh> that's why I asked frist
14:11:17 <ralonsoh> first
14:11:33 <ralonsoh> of course, I can create a new API for this
14:11:50 <mlavalle> and API is a gateway to access functionality, but it is also a language, with meaning
14:12:36 <TomStappaerts> What scenario is being solved here? Why do you need to set numa on port first, before VM is even there? (Sorry if I am not supposed to but in here :) )
14:13:09 <mlavalle> I'm not saying no, I am just trying to come up with a good explanation of why we are going to stretch the semantics of this API in this way
14:13:11 <ralonsoh> to define the numa node where the port and the vm are going to be spawn
14:13:31 <ralonsoh> mlavalle, I had the same concerns
14:13:45 <ralonsoh> I don't mind at all creating a new API
14:13:55 <ralonsoh> to store this info and pass it in the port info to Nova
14:14:31 <mlavalle> is there even a higher level abstraction that could encompass qos and numa?
14:15:18 <mlavalle> and probably is has to do with "scheduling"
14:15:21 <ralonsoh> as I commented, just for throughput optimization
14:16:07 <ralonsoh> we didn't plan to add any placement update
14:16:18 <ralonsoh> just add this info to the port to be used by nova
14:16:24 <slaweq> ok, lets say that it would be in QoS api, so how it would looks like? I mean this new rule type what parameters it would have?
14:16:43 <ralonsoh> just one: numa_node
14:16:48 <mlavalle> in the case of minimum bandwidth, we are already sending info to Nova in a port attribute, right?
14:17:00 <ralonsoh> yes
14:17:21 <ralonsoh> (I don't have now the patch)
14:17:25 <njohnston> So the question is, does this really pertain to QoS.  I would define QoS in a network context as a network's ability to achieve maximum bandwidth for the most important data by dealing with performance elements like latency, error rate, and traffic prioritization.  With that view in mind I don't think it's too much of a stretch to call this QoS.
14:18:04 <slaweq> ralonsoh: so if I will assign QoS Policy with such rule to e.g. network, all ports will have same rule, e.g. numa_node=0
14:18:15 <slaweq> does it makes sense at all?
14:18:47 <ralonsoh> the user is the owner of this qos and resources
14:19:16 <ralonsoh> but yes, if the user set a numa node in a qos policy, all resources will be attached to this numa node
14:19:24 <ralonsoh> (not networks but ports)
14:19:28 <njohnston> slaweq: I would think that a numa policy could only be assigned to a port, because assigning it to a network seems like an undefined concept to me
14:19:38 <ralonsoh> exactly
14:19:48 <slaweq> njohnston: yes, but currently QoS policy can be attached to the network
14:19:57 <ralonsoh> this rule can be applied to a qos policy and this policy can be set in a network
14:19:58 <ralonsoh> yes
14:20:15 <ralonsoh> but in this case, the same as with other rules
14:20:20 <slaweq> so because of that I tend to say - lets add new API instead of trying to reuse QoS API with some strange constraints
14:20:23 <ralonsoh> this policy will apply to the ports
14:20:29 <ralonsoh> no no
14:20:39 <ralonsoh> you can't apply qos rules to a network
14:20:52 <ralonsoh> but those rules will be inherited by the ports
14:20:55 <slaweq> I know that it is then inherited by ports
14:21:26 <mlavalle> in the case of minimum bandwidth, we add to ports a "resource_request" attribute. That attribute could be used to specify a nume resource requiremente. Couldn't it?
14:21:39 <ralonsoh> let me check
14:21:48 <ralonsoh> well yes
14:21:51 <slaweq> mlavalle: this attribute is currntly read only IIRC
14:21:52 <lajoskatona> but that field is a counted one not set by user
14:21:59 <ralonsoh> this is were I was planning to add this info
14:22:14 <mlavalle> we could generalize it by letting the user have access to it
14:22:17 <jkulik> What's the point in defining numa-node assignments in neutron instead of nova? What happens if a VM has multiple network ports with different numa assignments?
14:22:21 <mlavalle> through a new API
14:22:33 <slaweq> IMO we would need some new API with attribute like "numa_node" added to port - and internally we can put it in the "resource_request" when sending to nova
14:22:37 <ralonsoh> jkulik, that will be handled by Nova
14:22:41 <ralonsoh> we only provide the infop
14:22:54 <ralonsoh> slaweq, ok
14:23:07 <lajoskatona> if user can touch that could lead to broken info: different in qos rule than in port resource req. field
14:23:13 <TomStappaerts> So why not just supply it to nova, as it pertains to vm placement?
14:23:14 <lajoskatona> if user changed the values
14:23:31 <mlavalle> slaweq: yeah, but what if in the futute we need to add something new... why don't we generalize this mechanism and we create something that could be potentially extended in the future
14:24:07 <ralonsoh> TomStappaerts, nova can spawn a VM in any numa node, but it need also where the port is going to be created
14:24:43 <TomStappaerts> ralonsoh: But does it make more sense to provide this at port create instead of at server create in nova?
14:24:46 <ralonsoh> mlavalle, so you propose to have a generic container in "port" to be sent to Nova
14:25:06 <ralonsoh> TomStappaerts, when in Neutron we create a port, we only create a register in a DB
14:25:07 <lajoskatona> mlavalle: with extra care it can be possible but avoiding the user to change the bw (or latr whatever)allocation on port
14:25:13 <mlavalle> ralonsoh: yeah that can solve this problem and later can be extended for other purposes
14:25:22 <ralonsoh> TomStappaerts, we don't create anything in the backend
14:25:38 <ralonsoh> mlavalle, ok so let me resume this
14:25:44 <TomStappaerts> ok
14:25:55 <ralonsoh> 1) explain how this generic container can be populated
14:26:00 <mlavalle> summarize... resume means something else in English
14:26:01 <ralonsoh> 2) create a new API???
14:26:07 <lajoskatona> we thought resource_req as such general, but at that time without the user's hands in the picture :-)
14:26:12 <slaweq> mlavalle: You're right, and I think that we may have additional use case already with Cyborg
14:26:13 <ralonsoh> mlavalle, sorry!
14:26:15 <slaweq> mlavalle: see https://docs.google.com/document/d/11HkK-cLpDxa5Lku0_O0Nb8Uqh34Jqzx2N7j2aDu05T0/edit
14:26:46 * mlavalle undertsands perfectly well his fellow Spanish speaker ;-)
14:27:08 <ralonsoh> is (2) ok for you folks??
14:27:34 <mlavalle> yeah, we can have a new API to access and control this port attribute
14:27:58 <ralonsoh> perfect then
14:28:02 <slaweq> ralonsoh: yes
14:28:12 <lajoskatona> +1
14:28:18 <njohnston> +1
14:28:21 <ralonsoh> thanks a lot
14:28:27 <slaweq> but please check this document from Cyborg, I think we can have addressed both use cases at once
14:28:38 <ralonsoh> sure
14:28:58 <slaweq> ok, ralonsoh  so please propose a spec for that
14:29:15 <slaweq> and I think that also RFE would be good for tracking purpose :)
14:29:21 <ralonsoh> of course
14:29:46 <slaweq> ok, I think we can move on
14:29:59 <slaweq> next item (quick I hope) is from me
14:30:01 <slaweq> We are deprecating neutron-fwaas. What with the API-REF? It's question from the ML http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015508.html
14:30:20 <slaweq> My understanding is that we should deprecate fwaas api too
14:30:31 <slaweq> but I wanted to hear opinions from You also
14:30:32 <njohnston> I think amotoki’s answer is correct and definitive.
14:31:00 <jkulik> this would mean, that official openstack clients don't include that API anymore, right?
14:31:02 <njohnston> fwaas api is part and parcel of fwaas and lives or dies with it.
14:31:13 <njohnston> jkulik: correct
14:31:47 <seba> so, what would my options be if I have this api implemented in my custom network driver? maintain the API myself? move it into an extra project?
14:32:00 <slaweq> jkulik: I'm not sure about OSC as this API is still in stable branches which are supported
14:32:38 <jkulik> slaweq, but we have to anticipate it getting removed at some point in time - even if that time is a couple year.
14:32:50 <slaweq> jkulik: yes
14:32:58 <njohnston> does your implementation require any of the fwaas plugin code in neutron that was a part of the neutron-fwaas repo?
14:33:03 <slaweq> IMO that is what will happen with it
14:33:10 <lajoskatona> Isn't that possibe to make fwaas a pure API, like bgpvpn, but without backend implementation<
14:33:11 <lajoskatona> ?
14:33:50 <slaweq> lajoskatona: do You mean to keep API definition in the neutron-lib?
14:33:52 <slaweq> or what?
14:33:54 <mlavalle> that's an intresting idea
14:34:20 <lajoskatona> yes and Db (and whatever) in fwaas but without actually doing backend things
14:34:42 <lajoskatona> and let the possible users, maintainers to do the implementation with SDN or whatever project
14:34:48 <njohnston> I was going to say, we have not removed the API definition (yet); as long as you depend on zero code from the actual implementation of that API you could slip in and run it, we could leave it there.  I would want to amend the API ref document.
14:35:34 <mlavalle> and this way we keep serving a wider community
14:35:37 <jkulik> we haven't started implementing it, but it would probably only depend on the APIs being available to our customers
14:35:39 <mlavalle> who have trusted us
14:36:35 <jkulik> with a wide range of openstack client libraries, this would only be possible if the API is still documented as supported, I'd guess.
14:38:36 <njohnston> jkulik: I think here is how the process would go: you would create a new repo in the x/ namespace for your project, that implements everything that neutron-fwaas does.  If you want to revivie neutron-fwaas that is fine, but support of it is yours.  We can keep the API and OSC bits, and we clearly indicate that the backend to implement them is your project.
14:39:39 <slaweq> yeah, I think that this can work and we may leave this API definition in neutron-lib as "official" API
14:39:58 <jkulik> ok. sounds fine
14:40:00 <slaweq> but write in api-ref document that Neutron is NOT providing any official implementation of this API
14:40:12 <slaweq> njohnston: mlavalle lajoskatona is that what You meant?
14:40:17 <njohnston> yes
14:40:35 <mlavalle> +1
14:40:46 <njohnston> jkulik: will you be integrating with ML2/OVS, OVN, or a different ML2 plugin?
14:40:52 <lajoskatona> yes
14:41:32 <slaweq> ok, I will summarize that in the thread on ML today
14:41:33 <seba> jkulik and I have a custom cisco asr1k driver. fwaas should be realized also on this device
14:41:51 <slaweq> and I will also propose patch to api-ref to include this note there
14:42:02 <seba> the asr1k driver contains an l3 driver and an ml2 plugin
14:42:36 <njohnston> seba: Excellent, so you don't need any of the fwaas bits that plugged in to the ML2/OVS agent or l3 agent.
14:43:28 <njohnston> I am +1 for this approach overall
14:43:56 <slaweq> haleyb: any ideas? I think we need Your vote too :)
14:44:00 <seba> njohnston, exactly, we only need to be called by neutron (and our users need the api availability to use things like the official openstack cli client to use the api)
14:45:07 <slaweq> haleyb: maybe better question is "any thoughts?" :)
14:45:08 <haleyb> slaweq: +1 from me
14:45:13 <slaweq> great :)
14:45:16 <njohnston> fwaas has died, fwaas is risen, fwaas will come again
14:45:26 <slaweq> njohnston: :)
14:45:43 <slaweq> ok, so lets now talk about some RFEs
14:45:46 <jkulik> thank you
14:45:47 <slaweq> #topic RFEs
14:46:09 <slaweq> as we have TomStappaerts here, lets start with https://bugs.launchpad.net/neutron/+bug/1751040
14:46:09 <openstack> Launchpad bug 1751040 in neutron "[RFE] Extended resources should not always calculate all attributes" [Wishlist,Confirmed]
14:46:36 <TomStappaerts> Hi
14:48:45 <njohnston> I think this is a fantastic idea.  We definitely see that with each OSP version generally speaking Neutron seems to get slower for basic operations like list ports, and I think the resource extension framework is where the slowdown lies.
14:49:30 <TomStappaerts> The core problem for us as SDN provider is here that we cannot go to our SDN for every single port during listing as that would take ages and ages
14:50:01 <TomStappaerts> So we would only do that when "requested"
14:50:22 <slaweq> so is my understanding correct that it's something like e.g. when I do neutron port-list -c id -c fixed_ips neutron will not call e.g. QoS extension to check QoS policy for those ports?
14:50:31 <slaweq> as it's not needed at all in the result
14:50:40 <TomStappaerts> That would be the idea
14:50:40 <njohnston> TomStappaerts: Would it help if there was a bulk resource extend call that would take an array of ports so you could do it once instead of N times?
14:51:34 <njohnston> (note: bulk resource extend could be in addition to this RFE, it doesn't take away from the value of this RFE in my mind)
14:51:43 <TomStappaerts> njohnston: It would help indeed, one way it would help is that in that case we do not go to SDN or only do it for resources that can be gotten in bulk. But that is not this rfe indeed.
14:52:22 * njohnston was just brainstorming
14:53:08 <slaweq> TomStappaerts: one more question, do You plan to implement that in this cycle if we will approve RFE?
14:53:13 <TomStappaerts> We don't have any bandwidth in our team atm though, so I am able to join brainstorming and review but implementation itself I just don't have the time (read employer has other priorities).
14:53:46 <mlavalle> oh yeah. employers do that some times ;-)
14:53:54 <slaweq> yes, I know
14:53:59 <slaweq> just asking :)
14:54:52 <slaweq> I'm ok to approve this RFE as an idea. But I don't think we will implement it fast :/
14:55:13 <mlavalle> yes, let's approve it and we can revisit in a few months
14:55:39 <TomStappaerts> That is fine initially I think, If there is community support I can keep bringing it up here too; that it won't be wasted effort because no one wants it.
14:55:46 <njohnston> +1 from me, and yes let's not target to a release.  If anyone is getting interns it'd be a great research project.
14:56:57 <slaweq> haleyb: any thoughts?
14:57:27 <haleyb> slaweq: +1 from me
14:57:31 <slaweq> thx :)
14:57:34 * haleyb isn't thinking much at the moment
14:57:48 <slaweq> so I will mark this RFE as approved after the meeting
14:58:17 <slaweq> as we have only 2 minutes left I don't think we can really start next RFE today
14:58:28 <slaweq> so lets move other 2 for next week
14:58:41 <slaweq> thx for attending the meeting and have a great weekend :)
14:58:43 <njohnston> good discussions all
14:58:46 <njohnston> thanks
14:58:47 <slaweq> see You all on Monday
14:58:48 <ralonsoh> you too
14:58:50 <ralonsoh> bye
14:58:51 <njohnston> o/
14:58:53 <lajoskatona> bye
14:58:53 <slaweq> #endmeeting