15:01:05 <ralonsoh> #startmeeting neutron_qos
15:01:06 <openstack> Meeting started Tue Aug 27 15:01:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:09 <openstack> The meeting name has been set to 'neutron_qos'
15:01:09 <ralonsoh> hello
15:01:12 <davidsha> o/
15:01:24 <ralonsoh> same as previous meeting, there is no agenda today
15:01:28 <ralonsoh> no bugs or rfe
15:01:53 <ralonsoh> apart from
15:01:54 <ralonsoh> #
15:02:00 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1476527
15:02:01 <openstack> Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor D.C. (igordcard)
15:02:46 <ralonsoh> davidsha, I've seen that you have uploaded the spec
15:02:49 <ralonsoh> #link https://review.opendev.org/#/c/678865/1/specs/train/qos_classifier.rst
15:02:58 <ralonsoh> but is not finished yet
15:03:16 <davidsha> Yup, it's very basic at the moment, I still need to do the Proposed solutions
15:03:31 <ralonsoh> one question (we have discussed this before)
15:03:42 <davidsha> shot
15:03:53 <ralonsoh> is neutron classifier going to be something depending on QoS? an extension to the extension?
15:04:22 <ralonsoh> or will it have it's own entity
15:04:36 <davidsha> No, I think there had been other RFEs for other services to use it, one was for Security Groups I think
15:04:40 <ralonsoh> of course, if you want to use dscp, you'll need qos
15:04:49 <ralonsoh> ok
15:05:45 <ralonsoh> because this is very QoS centric, just to make this visible in the spec
15:05:53 <ralonsoh> that this is an independent extension
15:06:01 <davidsha> Yup, there are optional extensions and thats how I'm trying to implement the classifier, an optional extension to other extension.
15:06:14 <davidsha> Ack
15:06:23 <ralonsoh> so ping me once you have something to read there
15:06:31 <davidsha> Will do!
15:06:51 <ralonsoh> do you have any update on the POC? #link https://review.opendev.org/#/c/670050/
15:08:34 <davidsha> Yup, I'm going to redo the DB models to work closer to how you suggested, I think there might be some deviation though as I work, I'll comment as I go to explain why I changed things
15:09:07 <ralonsoh> perfect, thanks!
15:09:22 <davidsha> I haven't pushed that yet, will try to get it up asap, after that I'll try porting all the tests.
15:09:55 <ralonsoh> thank you davidsha
15:09:58 <ralonsoh> any other update on this RFE?
15:10:38 <davidsha> I have the DSCP patch rebased and it can be tested: https://review.opendev.org/#/c/636333/14
15:11:19 <davidsha> I'm also considering adding another field to DSCP to mark what priority the rule should be compared to the other DSCP Rules, what are your thought?
15:12:27 <ralonsoh> but first you should add the patch https://review.opendev.org/#/c/636333 to neutron
15:12:32 <ralonsoh> is that right?
15:13:39 <davidsha> Well it would be adding a classification-groups-id field and a classification-priority field to the DSCP rule in this patch
15:14:11 <ralonsoh> right
15:14:17 <davidsha> classification-priority being an positive integer rangeing from 0-X
15:14:39 <ralonsoh> but what does it means?
15:15:01 <ralonsoh> you can have several rukles for the same traffic?
15:15:11 <ralonsoh> and then only the high prio one will be used?
15:15:59 <davidsha> Kinda, ya, if one classification is for traffic from a host and another is for traffic to tcp port 80 which would take priority if both conditions match
15:16:29 <ralonsoh> ahhh ok,
15:16:33 <ralonsoh> the rules can overlap
15:16:37 <davidsha> yup
15:17:10 <ralonsoh> so you propose to have a priority index in the qos dscp rule
15:17:19 <davidsha> I know with openflow, it's not predicatble what will happen, when the traffic first hits the flow it will just use that for as long as the flow exists
15:17:25 <davidsha> yup
15:17:49 <ralonsoh> yes, I know OF is not deterministic on this
15:18:06 <ralonsoh> ok, perfect for me
15:18:17 <ralonsoh> btw, one question
15:18:39 <ralonsoh> should not https://review.opendev.org/#/c/636333 be on top of https://review.opendev.org/#/c/670050/?
15:19:39 <davidsha> It is, isn't it? Or do you mean the patch number?
15:19:54 <davidsha> like 636333 < 670050
15:19:56 <ralonsoh> not the number, the git precedence
15:20:04 <ralonsoh> no no, the git tree
15:20:50 <davidsha> Ya the git tree shuld have 6333 on 050
15:21:01 <ralonsoh> ok, just to make this clear
15:21:44 <ralonsoh> ok, any other update?
15:22:00 <davidsha> Nope, I think thats all from me, Thanks!
15:22:09 <ralonsoh> thank you davidsha
15:22:47 <ralonsoh> anything else? to those reading the meeting
15:23:25 <ralonsoh> thank you very much
15:23:30 <ralonsoh> see you next meeting
15:23:32 <ralonsoh> #endmeeting