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