15:01:14 <ralonsoh> #startmeeting neutron_qos
15:01:15 <openstack> Meeting started Tue Oct  8 15:01:14 2019 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:18 <openstack> The meeting name has been set to 'neutron_qos'
15:01:31 <ralonsoh> hello
15:01:32 <slaweq> o/
15:01:32 <davidsha> o/
15:01:35 * njohnston lurks
15:01:44 * slaweq will be lurking as is also on different meeting
15:02:05 <ralonsoh> #topic RFEs
15:02:31 <ralonsoh> I would like to add davidsha RFE to this section
15:02:42 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1476527
15:02:42 <openstack> Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor D.C. (igordcard)
15:03:13 <ralonsoh> I think this cycle we'll be able to push this feature in neutron
15:03:21 <ralonsoh> davidsha, do you think so?
15:03:29 <davidsha> ralonsoh, yup!
15:03:46 <ralonsoh> btw, you didn't update the spec
15:04:01 <ralonsoh> this is the first thing we need to approve
15:04:29 <ralonsoh> davidsha, are you going to push an update this week?
15:04:31 <davidsha> kk, I was going to get the refactor done first in case it resulted in the spec being updated
15:04:38 <ralonsoh> ok
15:04:52 <ralonsoh> because we should build this from the basement
15:05:05 <davidsha> +1
15:05:06 <ralonsoh> once the spec is approved, we can start merging the code
15:05:12 <ralonsoh> perfect, I'll wait for this
15:05:17 <ralonsoh> (this week??)
15:05:36 <davidsha> yup, I'll get the spec done tomorrow
15:05:41 <ralonsoh> perfect!
15:05:43 <ralonsoh> thanks davidsha
15:06:15 <ralonsoh> so next section
15:06:25 <ralonsoh> we don't have more RFEs
15:06:28 <ralonsoh> #topic Bugs
15:06:35 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1845176
15:06:35 <openstack> Launchpad bug 1845176 in neutron "Removing of QoS queue in neutron-ovs-agent fails due to existing references" [Medium,Confirmed]
15:07:03 <ralonsoh> this one usually happens during the FT tests
15:07:34 <ralonsoh> this is because when a qos register is going to be removed, all queues should be removed first
15:07:47 <ralonsoh> I'll take a look at this one this week
15:08:01 <ralonsoh> ok, next one
15:08:08 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1845161
15:08:09 <openstack> Launchpad bug 1845161 in neutron "Neutron QoS Policy lost on interfaces" [High,Confirmed] - Assigned to Nguyen Duy Binh (binhnd)
15:08:38 <ralonsoh> qos lost in interfaces when migrating or rebbot
15:08:47 <ralonsoh> I need to review this one better
15:09:55 <ralonsoh> the network backend is OVS
15:10:31 <ralonsoh> and this is testing only ingress max BW
15:10:50 <davidsha> Ya, it looks like maybe the QoS extension isn't being runn when the interfaces are being recreated on a hard reboot?
15:11:01 <ralonsoh> this is set in the interface, if I'm not wrong (policyng, not shapping)
15:11:19 <ralonsoh> hmmm I need to investigate this
15:11:55 <ralonsoh> but according to c#4, this is not happening always
15:12:05 <ralonsoh> you need to repeat this operation some times
15:12:27 <ralonsoh> ok, I'll take this one but not today or tomorrow
15:12:35 <davidsha> Ya, it's whats making me think that maybe it's skipping the QoS backend driver.
15:12:45 <davidsha> There is a patch submitted also
15:12:56 <davidsha> https://review.opendev.org/#/c/684457/1
15:13:29 <ralonsoh> I see where this is going
15:13:38 <ralonsoh> handle_port
15:13:46 <ralonsoh> if no change -> do nothing
15:13:58 <ralonsoh> but, of course, the interface qos must be applied again
15:14:07 <ralonsoh> I'll review this patch tomorrow
15:14:36 <davidsha> Ya, we had an issue before when we changed the behavior to "do nothing if no change"
15:15:11 <davidsha> Restarting the service would wipe the state of the port
15:15:54 <ralonsoh> this should be affecting only Train
15:16:02 <davidsha> kk
15:16:05 <ralonsoh> because this change (mine) was added last cycle
15:16:20 <ralonsoh> I remember adding this check: if no change, return
15:16:44 <ralonsoh> I think we need to check something else
15:17:02 <davidsha> kk, I'm thinking of a similar, older version of this, the solution back then was just apply every time.
15:17:26 <ralonsoh> yes
15:17:43 <ralonsoh> but what I don't know is what is happening when the port is deleted
15:17:56 <ralonsoh> because if the port is recreated
15:17:58 <ralonsoh> ...
15:18:01 <ralonsoh> never mind
15:18:08 <ralonsoh> the port is never deleted
15:18:20 <ralonsoh> only unbound and the bound again
15:19:06 <davidsha> that isn't necessarily triggering the handle_port call then is it?
15:19:57 <ralonsoh> no, if I'm not worng, those are the qos agent api callbacks
15:21:08 <ralonsoh> anyway, I'll take a look at this this week
15:21:16 <ralonsoh> something else related to bugs?
15:21:35 <davidsha> I think, handle_notifcation is the api callback, no, nothing from me.
15:22:35 <ralonsoh> yes, this is the api callback
15:22:58 <ralonsoh> the other method are the agent interface calls
15:23:13 <davidsha> yup, handle and delete port
15:23:41 <ralonsoh> ok, let's move
15:23:47 <ralonsoh> #topic Open Discussion
15:23:55 <ralonsoh> I have nothing in the agenda
15:24:00 <ralonsoh> do you?
15:24:36 <davidsha> Nothing important, I put this patch up just to make sure I don't lose it again: https://review.opendev.org/#/c/687256/
15:25:05 <lajoskatona> Hi
15:25:06 <ralonsoh> I'll add it to the etherpad
15:25:11 <ralonsoh> btw, davidsha
15:25:16 <davidsha> It's an improved CLI for the classifie
15:25:34 <ralonsoh> check the etherpad and add the list of patches under your RFE, if you want
15:25:41 <ralonsoh> https://etherpad.openstack.org/p/neutron_qos_meeting_chair
15:25:47 <ralonsoh> lajoskatona, hi
15:26:04 <lajoskatona> More a question or a note: we plan to make guaranteed minimum bandwidth feature work with ovn, and any suggestion can be helpful
15:28:00 <ralonsoh> lajoskatona, that means OVN needs to support min-bw
15:28:15 <ralonsoh> lajoskatona, although this qos rule won't do anything
15:28:29 <ralonsoh> the min-bw won't be applied on the backend
15:28:32 <lajoskatona> ralonsoh: even min-bw is not wokring with ovn, right now?
15:29:27 <ralonsoh> lajoskatona, I need to check but this is the same as OVS
15:30:13 <lajoskatona> ralonsoh: I see now in the code that only bandwidth-limit is there, ok so first it should be added to ovn qos-driver
15:30:23 <ralonsoh> lajoskatona, the problem is we need to introduce the qos code in the plugin project
15:30:31 <ralonsoh> yes
15:30:37 <ralonsoh> that's the point
15:30:45 <lajoskatona> ralonsoh: thanks, I check as well to have more details
15:30:51 <ralonsoh> btw, I don't know the status of QoS in OVN project
15:31:46 <ralonsoh> ok, something else in the agenda?
15:32:02 <davidsha> nothing from me
15:32:03 <lajoskatona> ralonsoh: side question: is there some "official" SIG like meeting or similar between OVN and networking-ovn (~neutron) team?
15:32:19 <ralonsoh> let me check that
15:32:28 <ralonsoh> slaweq, do you know that? ^^
15:32:31 <lajoskatona> ok, thanks
15:32:44 <lajoskatona> Sorry for trolling the meeting
15:32:55 <ralonsoh> http://eavesdrop.openstack.org/#Networking_OVN_and_ML2+OVS+DVR_Convergence_Team_Meeting
15:32:58 <slaweq> lajoskatona: there is meeting once in the month
15:33:12 <slaweq> exactly what ralonsoh just linked :)
15:33:18 <slaweq> nothing else for now
15:33:22 <lajoskatona> slaweq: thanks, good to know
15:33:27 <lajoskatona> ah, I see the link now
15:33:39 <lajoskatona> thnks for the info
15:34:00 <ralonsoh> lajoskatona, if you have plans to introduce qos to ovn, ping me to join those meetings
15:34:59 <lajoskatona> ralonsoh: thanks, I will ping you, and as I know our company plans rubasov will be there as well :-)
15:35:13 <ralonsoh> perfect
15:35:40 <ralonsoh> something else??
15:36:10 <ralonsoh> thank you all
15:36:14 <davidsha> Thanks!
15:36:19 <ralonsoh> and see you in 25 mins in the CI meeting
15:36:27 <ralonsoh> #endmeeting