15:01:03 <ralonsoh> #startmeeting neutron_qos 15:01:05 <openstack> Meeting started Tue May 21 15:01:03 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:08 <openstack> The meeting name has been set to 'neutron_qos' 15:01:08 <ralonsoh> hi! 15:01:22 <davidsha> Hey! 15:01:36 <ralonsoh> davidsha, I have you topic in Open Discussion 15:01:43 <davidsha> perfect! 15:02:00 <rubasov> hi 15:02:03 <lajoskatona> o/ 15:02:11 <mlavalle> it's waht we tyalked aboiut in Denver, right? 15:02:28 <ralonsoh> mlavalle, yes, the classifier 15:02:33 <mlavalle> cool 15:02:45 <ralonsoh> ok, let's go 15:02:46 <ralonsoh> #topic RFEs 15:02:51 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1578989 15:02:53 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,Fix released] - Assigned to Bence Romsics (bence-romsics) 15:03:02 <ralonsoh> We still have two patches under review 15:03:06 <ralonsoh> #link https://review.opendev.org/#/c/629142/ 15:03:07 <ralonsoh> #link https://review.opendev.org/#/c/629253/ 15:03:22 <ralonsoh> rubasov, lajoskatona any update? 15:03:54 <rubasov> lajoskatona: please go ahead 15:03:54 <lajoskatona> ralonsoh: yes, I think you refer to tempest tests 15:04:03 <ralonsoh> yes 15:04:18 <ralonsoh> I see you are still waiting for Nova 2.70 and 2.71 15:04:23 <lajoskatona> I think I started to get some review from tempest folks, so I hope that I can push them forward 15:04:53 <lajoskatona> ralonsoh: yes, I take over those patches to push mines :-) 15:05:28 <ralonsoh> ok, so your patch is rebased on top of those ones 15:05:29 <ralonsoh> perfect 15:05:36 <lajoskatona> ralonsoh: so I think the progress is slow, but there's some 15:05:37 <ralonsoh> I'll put this one in my review pile 15:05:48 <lajoskatona> ralonsoh: thanks 15:06:09 <ralonsoh> #link https://review.opendev.org/#/c/629253/ is still failing 15:06:56 <ralonsoh> ok, any other update on this RFE? 15:07:14 <rubasov> ralonsoh: not from me 15:07:39 <lajoskatona> ralonsoh: yeah, I wanted to check that after there some progress on the nova v2.70/71 schema checks 15:07:40 <ralonsoh> thank you! 15:07:56 <ralonsoh> lajoskatona, ok 15:08:19 <ralonsoh> perfect, next one 15:08:20 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1560963 15:08:21 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) 15:08:25 <ralonsoh> Slow progress 15:08:57 <ralonsoh> One patch is almost merged, but I need to send a new version for https://review.opendev.org/#/c/655969/ 15:09:06 <ralonsoh> I'll update the status next week 15:09:29 <ralonsoh> the last RFE I have 15:09:33 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1818479 15:09:34 <openstack> Launchpad bug 1818479 in neutron "RFE Decouple placement reporting service plugin from ML2" [Wishlist,Incomplete] - Assigned to Bence Romsics (bence-romsics) 15:09:45 <ralonsoh> I think this one has been discussed in the previous meeting 15:10:09 <rubasov> ralonsoh: that's another one 15:10:26 <ralonsoh> oh, yes!! 15:10:31 <ralonsoh> sorry 15:10:31 <rubasov> ralonsoh: this one we agreed on the ptg to postpone indefinitely 15:10:37 <mlavalle> yes 15:10:39 <ralonsoh> you are right 15:10:45 <mlavalle> we don't have the use case 15:10:56 <rubasov> I think I set it to Incomplete 15:11:00 <ralonsoh> do you want me to keep it there? I can freeze it for now 15:11:04 <rubasov> and added the rfe-postponed tag 15:11:30 <rubasov> it's probably a good idea to freeze it and not discuss every 2nd week 15:11:36 <ralonsoh> ok, I'll remove it from the etherpad for now 15:11:38 <rubasov> because there won't be much happening 15:11:45 <rubasov> ralonsoh: thank you 15:11:49 <ralonsoh> thanks! 15:11:54 <ralonsoh> next topic 15:11:55 <ralonsoh> #topic Bugs 15:12:01 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1824095 15:12:02 <openstack> Launchpad bug 1824095 in neutron "Fullstack job broken in stable/stein branch" [High,Fix committed] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) 15:12:17 <ralonsoh> an small problem with fullstack tests 15:12:21 <ralonsoh> solved in https://review.opendev.org/#/c/651458/ 15:12:35 <ralonsoh> I'll remove this one from the backlog, just for the records 15:12:44 <ralonsoh> next one 15:12:46 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1826695 15:12:47 <openstack> Launchpad bug 1826695 in neutron "[L3][QoS] cache does not removed when router is down or deleted" [Medium,In progress] - Assigned to LIU Yulong (dragon889) 15:12:59 <ralonsoh> patch #link https://review.opendev.org/#/c/656105/ 15:13:23 <ralonsoh> liuyulong, hi 15:13:35 <liuyulong> hi 15:13:50 <ralonsoh> about https://review.opendev.org/#/c/656105/ and slaweq's comment 15:14:13 <ralonsoh> will you push a fullstack test for this one? 15:14:29 <liuyulong> I will 15:15:03 <ralonsoh> perfect, IMO, the code is OK now 15:15:14 <liuyulong> A long test case, set router floating IP QoS, set router down and up. 15:15:27 <liuyulong> Then verify the TC rules. 15:16:12 <ralonsoh> both when the router is up, then down and up again 15:16:32 <ralonsoh> not both, in those three statuses 15:17:04 <liuyulong> admin_state down/up, this is the point to bugs. 15:17:50 <ralonsoh> ok, just to verify the first UP status is the same as the second 15:17:52 <liuyulong> The patch is now based on this: https://review.opendev.org/#/c/656163/ 15:17:53 <ralonsoh> but it's ok 15:18:29 <liuyulong> That l3 agent lock minimizing patch. 15:18:44 <ralonsoh> yeah, well, I still have some concerns about https://review.opendev.org/#/c/656163/ and the helpers used 15:18:52 <ralonsoh> in https://review.opendev.org/#/c/656163/8/neutron/common/coordination.py 15:19:11 <ralonsoh> but this is other topic and we can discuss it in the review 15:19:33 <liuyulong> Sure 15:19:51 <ralonsoh> thank you very much! 15:20:15 <ralonsoh> I don't have more QoS bugs in the list, am I missing someone? 15:20:59 <ralonsoh> cool, next topic 15:21:01 <ralonsoh> #topic Open Discussion 15:21:07 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1476527 - Adoption of Neutron Classifier API into QoS 15:21:08 <openstack> Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor D.C. (igordcard) 15:21:15 <ralonsoh> the main patch is #link https://review.openstack.org/#/c/636333 15:21:35 <ralonsoh> I have some concerns about it 15:22:16 <ralonsoh> this patch is modifying the DB and making references to an external project (classifier) 15:23:02 <ralonsoh> I tried to figure out how to make those API and DB changes generic and not dependant on the classifiers (classifications groups in the QoS rule DSCP) 15:23:17 <ralonsoh> but I didn't find the way 15:23:30 <ralonsoh> https://review.opendev.org/#/c/636333/9/neutron/db/migration/alembic_migrations/versions/stein/expand/cd28a37b069f_classifier_dscp.py 15:23:53 <ralonsoh> the main problem here is https://review.opendev.org/#/c/636333/9/neutron/db/migration/alembic_migrations/versions/stein/expand/cd28a37b069f_classifier_dscp.py@103 15:24:19 <ralonsoh> adding the possibility to create several dscp rules per QoS policy 15:24:38 <ralonsoh> but depending on something that doesn't exist in Neutron, the classification groups 15:24:48 <ralonsoh> davidsha, ? 15:25:24 <davidsha> If NC isn't part of a deployment then that would function the same as the original unique constraint 15:26:31 <davidsha> classification_group being None and it couldn't create a duplicate with None as the classification group, is that the concern? 15:27:20 <ralonsoh> by default, "classification_group_id" can't be a reference to another table ID 15:27:23 <ralonsoh> right? 15:27:38 <davidsha> yup, it defaults to None 15:28:28 <ralonsoh> mlavalle, is OK to have something like this in the dscp table? a parameter which, by default, is going to be None and if NC is loaded, it will be populated 15:28:31 <ralonsoh> ? 15:29:14 <mlavalle> I'd say yes 15:29:43 <mlavalle> what is your concern about it? 15:30:12 <ralonsoh> because we'll have something like "classification_group_id" in that table 15:30:25 <ralonsoh> but this is something not directly related to Neutron, only Neutron 15:30:36 <davidsha> A DB entry thats always there and unless an external project is enabled can't be anything but None 15:30:57 <ralonsoh> BTW, for me is OK 15:31:10 <ralonsoh> I'm just the devil advocate here 15:31:45 <ralonsoh> the other concern is: how to "fill" correctly the agents qos extension 15:31:47 <davidsha> kk, It was the way it needed to be written, just the way DB migrations work for extensions 15:32:11 <ralonsoh> ok 15:32:19 <ralonsoh> about the agent extensions 15:32:21 <ralonsoh> https://review.opendev.org/#/c/636333/9/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py 15:32:23 <mlavalle> I'm ok with it 15:32:37 <ralonsoh> mlavalle, perfect 15:33:25 <ralonsoh> davidsha, how the agents are going to add the classification information in the dscp rules? will you create something like a QoS extension? 15:34:45 <davidsha> ralonsoh: It went out of scope of Neutron Classifier about the actual backend implementation, It was always presumed that the consuming extension would be the one implementing the classification 15:35:34 <ralonsoh> but the drivers should need to have this information 15:35:50 <davidsha> As in the classification definition? 15:36:02 <ralonsoh> the dscp rules are going to be different depending on if the NC is loaded 15:36:12 <davidsha> Yes 15:36:33 <davidsha> This is done through the agent extensions API 15:36:36 <davidsha> https://review.opendev.org/#/c/636333/9/neutron/agent/common/agent_extension_api.py 15:37:01 <ralonsoh> yes, that's the point 15:37:27 <ralonsoh> this code refers to something that doesn't exist in Neutron 15:38:05 <davidsha> Specifically this part, or generally 15:38:08 <davidsha> ? 15:38:45 <ralonsoh> what you are doing here is to create a base agent extension, inherited by the other extensions 15:39:11 <ralonsoh> adding API calls to something that doesn't exist in Neutron, the classification groups 15:40:43 <ralonsoh> ? 15:40:48 <davidsha> agent extension APIs*(just to clarify), Ya, it functions in the same way QoS would retrieve the definitions of it's QoS Policies 15:41:41 <davidsha> but This is something inside Neutron that would need something in Neutron Classifier to propegate the Classification definitions 15:42:36 <ralonsoh> I know, but as I said, we introduce the concept of classification groups in Neutron but Neutron doesn't know anything about this 15:42:57 <ralonsoh> this is not even an in-tree extension 15:43:09 <ralonsoh> although we add it 15:44:10 <ralonsoh> davidsha, ? 15:44:45 <ralonsoh> sorry for being a pain in the neck 15:45:09 <davidsha> It's fine, I'm just trying to find words ;P 15:46:18 <davidsha> This is kinda just the result of how the original approval team wanted this implemented, I'm not sure how to work around it 15:46:53 <ralonsoh> mlavalle, is that ok to have something like this in Neutron? 15:46:54 <ralonsoh> https://review.opendev.org/#/c/636333/9/neutron/agent/common/agent_extension_api.py 15:47:09 * mlavalle looking 15:48:22 <mlavalle> we seem to be stumbling with the same thing, don't we? 15:48:54 <mlavalle> it;s the fact that we are using something that is external and that we don't know about 15:48:56 <mlavalle> right? 15:49:03 <ralonsoh> that's the point 15:49:12 <davidsha> Ya, it's the introduction of a soft external dependency 15:49:43 <mlavalle> but how is this "library" different from say neutron-lib? 15:50:27 <davidsha> It's a service plugin + extension rather than a library. 15:50:28 <mlavalle> it's a library, after all, right? 15:50:55 <davidsha> It creates resources to model classifications for other Neutron resources to consume. 15:51:37 <mlavalle> so we are creating a comsumption model in Neutron that didn't exist before? 15:51:58 <mlavalle> should we have an abstraction layer in Neutron to consume it? 15:52:06 <davidsha> yes, but through the AgentExtensionAPI which has been there sine newton. 15:52:26 <mlavalle> ahhh, that's the abstraction layer 15:53:16 <davidsha> Yup, its how l2/l3 extensions can retrieve info from the agents. 15:54:12 <davidsha> NC is adding an extra bit so that extensions can ask it what a classification group id actually means. 15:55:55 <mlavalle> I think I need to spend some time with https://review.opendev.org/#/c/636333 15:56:06 <mlavalle> to wrap my mind around it 15:56:23 <davidsha> kk, thanks 15:56:28 <ralonsoh> mlavalle, I'll ping slaweq for this too, if he has some time 15:56:38 <mlavalle> ok 15:57:22 <ralonsoh> davidsha, sorry but we need to find a way to introduce NC in a good way 15:57:34 <davidsha> ack, thats fair 15:57:51 <ralonsoh> ok, guys, almost time to finish the meeting 15:57:57 <ralonsoh> something else in the agenda? 15:58:01 <davidsha> There was a suggestion to move the Service plugin itself into Neutron, is that feasible? 15:58:24 <ralonsoh> davidsha, I don't remember this suggestion 15:58:32 <ralonsoh> who did it? 15:58:58 <davidsha> ralonsoh: kk, I thought you mentioned it at the PTG, I must have misunderstood 15:59:13 <njohnston> I never understood why NC was not done inside neutron-lib 15:59:30 <ralonsoh> njohnston, that could be a good solution 15:59:43 <ralonsoh> anyway guys, we need to finish now 15:59:47 <ralonsoh> thank you all 15:59:54 <davidsha> njohnston, if it was a Mixin for things to include, it would make sense, but not a resource unto itself I think 16:00:03 <davidsha> thanks! 16:00:07 <ralonsoh> #endmeeting