15:00:58 <ralonsoh> #startmeeting neutron_qos
15:01:03 <openstack> Meeting started Tue Jul 30 15:00:58 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:06 <ralonsoh> hello
15:01:07 <openstack> The meeting name has been set to 'neutron_qos'
15:01:46 <slaweq> hi
15:02:03 <ralonsoh> he don't have agenda, but the qos classification
15:02:08 <ralonsoh> i'm waiting for davidsha
15:02:21 <davidsha> Hey
15:02:44 * njohnston lurks
15:03:08 <ralonsoh> so, as commented, there is no agenda
15:03:12 <ralonsoh> no RFEs
15:03:14 <ralonsoh> no bugs
15:03:27 <ralonsoh> #topic Open Discussion
15:03:33 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1476527
15:03:34 <openstack> Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor D.C. (igordcard)
15:03:54 <davidsha> njohnston: Does that change on https://review.opendev.org/#/c/670050/2 work for you? I remember a tonne of semantic discussions early on in neutron-classifier about classifier vs classification
15:04:22 <ralonsoh> davidsha, I'm still writing a review in your neutron and n-lib patches
15:04:23 <njohnston> davidsha: Yes that works great for me!
15:04:46 <ralonsoh> davidsha, ok, let me push what I have now
15:04:59 <ralonsoh> davidsha, I would like, for the records, one thing
15:05:30 <davidsha> I updated the endpoint to classification based on comments, which is the main change since last update, I'm going to try and add in the propagation code to the various neutron agents, but mainly L2 for the moment.
15:05:32 <ralonsoh> I don't understand the relationship between ClassificationGroup, CGToClassificationMapping and CGToClassificationGroupMapping
15:06:48 <davidsha> ralonsoh: CGToClassificationMapping maps classifications to classification groups and CGToClassificationGroupMapping maps classification groups to classification groups.
15:08:09 <ralonsoh> davidsha, can you explain how this mapping is done
15:09:44 <davidsha> On creation when you pass in what classification/classification group objects compose a classification group, the service plugin will create a mapping from the newly created classification group to the previously created classification/classification group, there is no update mechanism for this to avoid a circular dependency at the moment
15:10:30 <ralonsoh> so you can have two classifications and you can create a CG
15:10:48 <ralonsoh> and then one CG and one C, and you can create a second CG
15:10:58 <ralonsoh> like a binary tree
15:11:00 <davidsha> Yup
15:11:07 <ralonsoh> okidoki, understood
15:11:29 <ralonsoh> now I need to retake the POC in neutron to review the DB definition
15:11:30 <ralonsoh> btw
15:11:32 <ralonsoh> in the n-lib
15:11:36 <ralonsoh> one sec
15:12:01 <ralonsoh> https://review.opendev.org/#/c/670049/
15:12:28 <ralonsoh> you are missing a lot of information
15:12:39 <ralonsoh> name, description, timestamp, etc
15:13:03 <ralonsoh> that's why in the neutron patch,  here https://review.opendev.org/#/c/670050/2/neutron/extensions/classification.py
15:13:20 <ralonsoh> you use api_ext.ExtensionDescriptor, instead of APIExtensionDescriptor
15:13:44 <ralonsoh> anyway, I still need to review the n-lib patch
15:14:06 <ralonsoh> another question
15:14:09 <davidsha> kk, I wasn't sure how much was necessary and how much was for this instance. I'll update this
15:14:23 <ralonsoh> class ClassificationBase()
15:14:44 <ralonsoh> why do you need it? this is not a classification itself
15:15:44 <ralonsoh> there should not be a DB definition of this generic classification, or at least you should have a class not inheriting from model_base.BASEV2
15:16:03 <ralonsoh> and then inherit it from the classification type classes
15:17:21 <ralonsoh> is that ok for you?
15:17:45 <davidsha> Ack, We used it initially for a generic pull in the classification and then use it to find out which classification it was specifically. I'll remove model_base.BASEV2, I'll see do we need it for the previous functionality still.
15:18:10 <ralonsoh> do you need a generic classification table?
15:19:01 <davidsha> For now, I'll say we do, but it can be refactored out
15:19:42 <ralonsoh> what is the goal/use of this generic type?
15:20:04 <ralonsoh> there won't be a classification base on this generic type
15:20:19 <ralonsoh> same a in QoS: there is no generic QoS rule
15:20:25 <ralonsoh> you have max, min or dscp
15:20:49 <davidsha> We have it here on line 65: https://review.opendev.org/#/c/670050/2/neutron/db/migration/alembic_migrations/versions/train/expand/ae8df423b477_neutron_classifier.py
15:21:56 <ralonsoh> yes, the migration and the db definition should be the same
15:22:08 <ralonsoh> but my question is: do you need this generic classification?
15:22:28 <ralonsoh> you have ipv4, 6, udp, ethernet and tcp
15:22:37 <ralonsoh> 5 types, if I'm not wrong
15:22:48 <davidsha> At the moment yes, it handles how classifcations can be retrieved only with they're ID when you don't know what type that ID is
15:23:49 <davidsha> There are 5 types, but when we were scoping out an RFE to enable security groups with Neutron classifier I think it would involve about 40 different protocols
15:24:29 <ralonsoh> yes, but you can build a classification only with known types
15:24:41 <ralonsoh> now those types are these 5
15:24:44 <ralonsoh> only
15:25:50 <davidsha> Not necessarily, for the backend, it only provides the ID, it doesn't have what types the classifications are.
15:27:08 <ralonsoh> the backend won't know what the classifications are?
15:27:23 <ralonsoh> how are you going to implement the DSCP rules without this information?
15:27:29 <ralonsoh> in the backend
15:27:57 <ralonsoh> if you don't have this info, how are you going to config, for example, linux bridge with those specific dscp rules?
15:28:34 <davidsha> They do know the type by the time it's consumed, but it's just being provided classification group id as an arguement.
15:29:38 <ralonsoh> ok, I still don't know why we need a generic classification table
15:29:47 <ralonsoh> please, comment it in the review
15:29:53 <ralonsoh> I don't see any reason for that
15:30:14 <ralonsoh> as said, for me this is the same as the qos rules: there is no generic type
15:30:40 <amotoki> mlavalle: slaweq: I updated the neutron bug deputy schedule by adding a column of "note". we can keep the order :)
15:31:15 <slaweq> amotoki: thx, but please don't disturb qos meeting here :)
15:31:18 <amotoki> woops.... I thought I was in #-neutron channel. sory
15:31:22 <ralonsoh> hahahaha
15:31:25 <ralonsoh> no problem amotoki
15:31:34 <davidsha> kk, I'll respond, it's basically to do with the API only having a "Classification" type, and the DB having the subtypes based on their definitions, I'll clarify in the patch
15:32:33 <ralonsoh> davidsha, thank you! I need to understand this better
15:32:41 <ralonsoh> just one last thing
15:32:51 <ralonsoh> both patches (neutron and n-lib)
15:32:55 <ralonsoh> are the server part
15:33:05 <ralonsoh> did you try  the agent implementation?
15:33:15 <ralonsoh> which backend are you using?
15:33:52 <davidsha> Ya, my next update is migrating in the advertiser and the classification AgentExtenionsAPIMixin that I had in the other patch
15:34:14 <davidsha> For the moment, I'm test with OvS
15:34:18 <ralonsoh> okidoki
15:34:24 <ralonsoh> and about the spec
15:34:36 <ralonsoh> do you have something written down?
15:35:08 <davidsha> Spec for the QoS integration? No, I'll start that now
15:35:23 <ralonsoh> (you know this is not going to be approved for train, but just to start reviewing it)
15:35:52 <davidsha> There is the one we used for defining the Classification API that was merged into Neutron Specs
15:35:55 <davidsha> kk
15:36:22 <ralonsoh> yes, but the justification to integrate this in Neutron
15:36:23 <ralonsoh> you should be ready to present it in Shanghai
15:36:31 <davidsha> kk
15:36:52 <ralonsoh> that was a good "interrogatory"!!
15:36:57 <ralonsoh> thank you davidsha
15:37:07 <davidsha> no prob, thanks!
15:37:24 <ralonsoh> is there something else to be discussed today in this meeting?
15:38:11 <ralonsoh> I think we can finish here
15:38:14 <ralonsoh> thank you all
15:38:22 <davidsha> cool, thanks!
15:38:24 <ralonsoh> #endmeeting