15:00:39 <ralonsoh> #startmeeting neutron_qos
15:00:44 <mlavalle> o/
15:00:44 <openstack> Meeting started Tue Feb 12 15:00:39 2019 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:45 <ralonsoh> Hello
15:00:48 <openstack> The meeting name has been set to 'neutron_qos'
15:00:52 <mlavalle> Hola
15:00:56 <rubasov> o/
15:00:57 <ralonsoh> hola!
15:01:32 <ralonsoh> let's give some time, one more minute
15:01:40 <mlavalle> no problem
15:02:12 <ralonsoh> davidsha, if we have time, at the end, we have your topic in the agenda
15:02:21 <ralonsoh> let's start
15:02:23 <ralonsoh> #topic RFEs
15:02:31 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1578989
15:02:32 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Bence Romsics (bence-romsics)
15:02:37 <ralonsoh> links -->
15:02:43 <ralonsoh> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:minimum-bandwidth-allocation-placement-api
15:02:43 <ralonsoh> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/bandwidth-resource-provider
15:02:43 <ralonsoh> #link https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placement-api+(status:open+OR+status:merged)+project:openstack/tempest
15:02:44 <ralonsoh> #link https://review.openstack.org/#/c/629253/
15:02:45 <patchbot> patch 629253 - tempest - Minimum bandwidth allocation with placement - 6 patch sets
15:02:54 <ralonsoh> rubasov, any update?
15:02:54 <rubasov> I guess that's mine :-)
15:03:15 <rubasov> since we're close to freeze I'll try to give a thorough update
15:03:28 <rubasov> I think we're on good track to merge this in stein
15:03:38 <rubasov> stuff in review:
15:03:53 <rubasov> lajoskatona's end to end test in tempest (series): https://review.openstack.org/629142
15:03:55 <patchbot> patch 629142 - tempest - Add QoS policies and minimum bandwidth rule client - 5 patch sets
15:04:12 <rubasov> rubasov's neutron patch series (placement sync and changes to port binding) (series): https://review.openstack.org/630999
15:04:12 <patchbot> patch 630999 - neutron - New agent attribute: resources_synced - 6 patch sets
15:04:28 <rubasov> the last patch in the neutron series will need a new neutron-lib release
15:05:01 <rubasov> if these get merged the neutron side of the feature is basically working
15:05:09 <ralonsoh> rubasov, maybe you can ask boden if this is a good time for it (to add https://review.openstack.org/#/c/626210/)
15:05:10 <patchbot> patch 626210 - neutron-lib - New agent attribute: resources_synced (MERGED) - 5 patch sets
15:05:24 <mlavalle> rubasov: is the stuff you need in neutron-lib already merged?
15:05:29 <ralonsoh> yes
15:05:37 <rubasov> it's merged, but not released
15:05:43 <ralonsoh> patch: https://review.openstack.org/#/c/626210/
15:05:43 <patchbot> patch 626210 - neutron-lib - New agent attribute: resources_synced (MERGED) - 5 patch sets
15:05:52 <rubasov> ralonsoh: I'll ask boden
15:05:58 <ralonsoh> perfect
15:06:26 <ralonsoh> and then we still have 5 patches in out side (Neutron), to be reviewed
15:06:26 <rubasov> stuff in flight still for stein:
15:06:35 <mlavalle> rubasov: ok, if you need help with that, please ping me
15:06:47 <rubasov> mlavalle: will do, thanks
15:07:05 <rubasov> a fullstack test for the recovery of transient errors in placement sync: lajoskatona is working on it
15:07:21 <rubasov> a patch to reject as NotImplemented: update of qos min-bw rule on bound ports: rubasov is working on it
15:07:35 <rubasov> networking guide chapter on the feature: rubasov will work on it after the previous one
15:08:09 <rubasov> do you think we are missing anything else (on neutron side) for stein?
15:08:46 <ralonsoh> rubasov: so you will stop any qos update for bound ports, for now, is that correct?
15:08:57 <ralonsoh> qos update for min-bw
15:09:00 <rubasov> ralonsoh: only for min-bw rules
15:09:18 <rubasov> ralonsoh: yes
15:09:21 <ralonsoh> ok
15:09:56 <rubasov> for example do we need any other kind of documenatation beyond api-ref and networking guide?
15:10:42 <ralonsoh> IMO, everything related to placement + qos should be there (api-ref and networking)
15:10:52 <ralonsoh> placement + BW scheduling
15:11:07 <rubasov> ralonsoh: ok
15:11:25 <rubasov> then a bit about the nova side
15:11:33 <ralonsoh> of course, if needed, we can add more documentation on demand
15:11:38 <rubasov> maybe gibi pops up and corrects me :-)
15:11:44 <ralonsoh> sure, in the nova side for the sheduling
15:11:48 <rubasov> to my understanding the nova side of the feature has made really good progress
15:11:53 <rubasov> lots and lots of changes were merged
15:12:04 <rubasov> if you want to test end to end there's one gotcha:
15:12:13 <rubasov> the current patch series in nova leaves the feature turned off
15:12:19 <rubasov> there will be a patch still in stein turning it on (introducing a new microversion)
15:12:25 <rubasov> but until then you have to flip this
15:12:29 <rubasov> https://github.com/openstack/nova/blob/ac1fafb84c94ed9f8e610c7c3e152e38aef844ed/nova/api/openstack/common.py#L552
15:12:46 <gibi> rubasov i scorrect
15:13:10 <gibi> I'm in the process to propose the last patch that introduces the new microversion in the nova API
15:13:13 <ralonsoh> rubasov, good stuff for testing, thanks!
15:13:22 <rubasov> ralonsoh: of course
15:14:02 <rubasov> that's about all I had in mind
15:14:34 <ralonsoh> rubasov, gibi and lajoskatona: thank you very much!
15:15:01 <rubasov> ralonsoh: thanks for the reviews
15:15:26 <ralonsoh> let's move to the next one
15:15:27 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1777627
15:15:29 <openstack> Launchpad bug 1777627 in neutron "RFE: QoS – rule's management (set,delete, show…) requires <qos-policy> parameter in addition to <rule-id>" [Wishlist,In progress] - Assigned to Miguel Lavalle (minsel)
15:15:35 <mlavalle> for this one
15:15:37 <ralonsoh> #link https://review.openstack.org/#/c/613820/: a couple of review comments to be addresses
15:15:38 <patchbot> patch 613820 - neutron - Define qos-rules-alias extension - 5 patch sets
15:15:43 <ralonsoh> addressed
15:16:19 <mlavalle> I need to deploy the patch and do the final testing
15:16:34 <mlavalle> with my job change, my dev infra is in "flux"
15:16:47 <mlavalle> but I am getting to a point where I can deploy this week
15:16:58 <mlavalle> so I intend to finish it this week
15:17:36 <ralonsoh> mlavalle, if you want extra help, ping me
15:17:53 <mlavalle> ralonsoh: I will, thanks
15:18:31 <ralonsoh> ok, let's move to the next one
15:18:33 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1796925
15:18:34 <openstack> Launchpad bug 1796925 in neutron "[RFE] port forwarding floating IP QoS" [Wishlist,Fix released] - Assigned to LIU Yulong (dragon889)
15:18:39 <ralonsoh> #link https://review.openstack.org/#/c/631448/
15:18:40 <patchbot> patch 631448 - neutron - Add port forwarding floating IP QoS (MERGED) - 5 patch sets
15:18:47 <ralonsoh> The patch was merged last week
15:18:58 <ralonsoh> this patch was for the agent and the server side
15:19:41 <ralonsoh> liuyulong, do you think we can close this RFE?
15:20:07 <liuyulong> No, I'm working on the DOC.
15:20:20 <mlavalle> thanks liuyulong
15:20:26 <ralonsoh> liuyulong, ok, perfect (yes, I always forget the docs)
15:20:38 <mlavalle> BTW, let's not forget to congratulate our new Neutron core, liuyulong
15:20:46 <ralonsoh> liuyulong+++
15:20:58 <ralonsoh> congrats!
15:21:02 <davidsha> congrats!
15:21:07 <liuyulong> Thanks, : )
15:21:38 <mlavalle> liuyulong: did you have a great Spring Festival? Happy new year
15:22:33 <ralonsoh> (he's still celebrating!)
15:22:44 <mlavalle> it seems so. LOL
15:22:55 <ralonsoh> last one
15:22:56 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1560963
15:22:58 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:23:02 <ralonsoh> #link https://review.openstack.org/#/q/topic:bug/1560963+(status:open)
15:23:16 <ralonsoh> patches are in good shape, lots of reviews
15:23:21 <ralonsoh> addressing last comments
15:23:33 <ralonsoh> no blockers, no problem
15:23:39 <mlavalle> Great. Thanks
15:24:01 <ralonsoh> just one comment: https://review.openstack.org/#/c/406841/
15:24:01 <patchbot> patch 406841 - neutron - Add QoS minimum egress bandwidth rule into ovs-agent - 21 patch sets
15:24:23 <ralonsoh> I know this patch is big and scary, but you are welcome to review it
15:24:50 <ralonsoh> (maybe if I don't have reviews, I'll split it)
15:25:00 <mlavalle> the ones for network segment range management are scarier
15:25:11 <mlavalle> it's ok
15:25:16 <ralonsoh> hehehe
15:25:22 <mlavalle> we are machos here and we can take it
15:25:26 <ralonsoh> hahahahaha
15:25:55 <ralonsoh> and that's all for RFEs
15:25:58 <ralonsoh> #topic Bugs
15:26:07 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1812576
15:26:08 <openstack> Launchpad bug 1812576 in neutron "L2 agent do not clear old QoS rules after restart" [Medium,Fix released] - Assigned to Chengqian Liu (liuchengqian90)
15:26:13 <ralonsoh> #link https://review.openstack.org/#/c/632014/
15:26:14 <patchbot> patch 632014 - neutron - Clear old rules that have been applied before appl... (MERGED) - 27 patch sets
15:26:26 <ralonsoh> patch merged, congrats!
15:26:34 <ralonsoh> I'll remove it from the list next week
15:26:42 <ralonsoh> next one
15:26:43 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1785189
15:26:44 <openstack> Launchpad bug 1785189 in neutron "Floatingip and router bandwidth speed limit failure" [Medium,In progress]
15:26:55 <ralonsoh> #link: https://review.openstack.org/#/c/596637/
15:26:55 <patchbot> patch 596637 - neutron - Fix bug when floatingip and router bandwidth speed... - 4 patch sets
15:27:10 <ralonsoh> ok, let's see
15:27:22 <ralonsoh> I replied in the bug and launchpad
15:27:45 <ralonsoh> I tested this by using iperf both in the route namespace and in a VM
15:27:59 <ralonsoh> of course, the VM test makes more sense, but is almost the same
15:28:14 <mlavalle> thanks for verifying it
15:28:37 <ralonsoh> If I define, in the filtered interface (the one shaping the traffic)
15:28:46 <ralonsoh> a MTU of 64KB
15:29:06 <ralonsoh> and the traffic doesn't exceed this MTU (it's not possible, BTW)
15:29:36 <ralonsoh> there is not ip fragmentation and no retransmissions (just a few)
15:29:57 <ralonsoh> I tested several BW and I don't see any performance degradation
15:30:36 <ralonsoh> and, BTW, the packets inside the filter won't be augmented (with new headers or anything else)
15:31:04 <ralonsoh> so, IMO, 64KB (for IPv4 the maximum allowed size) is enough
15:31:09 <mlavalle> ok
15:31:16 <mlavalle> great work
15:31:20 <ralonsoh> more info in the bug, that's all
15:31:25 <davidsha> thanks
15:32:02 <davidsha> mlavalle: would floating ip bw be something to keep in mind when working on ovs dvr?
15:32:31 <mlavalle> davidsha: I think it is
15:32:48 <davidsha> mlavalle: kk
15:32:55 <mlavalle> but we can release implement it first without worrying about it
15:33:10 <mlavalle> get it working and then we iterate with the QoS stuff
15:33:36 <mlavalle> we cannot implement everythin at the same timne
15:33:51 <davidsha> True!
15:34:45 <ralonsoh> ok, let's go for the last bug
15:34:54 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/1815618
15:34:56 <openstack> Launchpad bug 1815618 in neutron "cannot update qos rule" [High,Confirmed] - Assigned to Bence Romsics (bence-romsics)
15:35:04 <ralonsoh> created 42 mins ago
15:35:08 <rubasov> I just opened that :-)
15:35:13 <ralonsoh> yes
15:35:20 <ralonsoh> I didn't have time to review it
15:35:33 <ralonsoh> rubasov, do you know what is happening?
15:35:40 <rubasov> it's a small problem of updating some qos rules with osc
15:36:14 <rubasov> I didn't fully locate the client side of it yet - whether it's in pyhton-openstackclient or python-neutronclient
15:36:22 <rubasov> but I can clearly reproduce it
15:36:33 <rubasov> and I see in tcpdump what's the problem
15:37:04 <rubasov> also the server side request validation could be improved to avoid a 500 internal server error
15:37:09 <ralonsoh> that means, probably, is in the server side
15:37:19 <rubasov> only some of it
15:37:29 <rubasov> neutronclient can update
15:37:31 <rubasov> osc cannot
15:37:38 <ralonsoh> hmmm
15:37:57 <ralonsoh> btw, you have assigned yourself this patch
15:38:01 <ralonsoh> bug
15:38:09 <ralonsoh> are you going to work on it?
15:38:13 <rubasov> yep, I'll go on fixing it
15:38:18 <ralonsoh> perfect!!
15:38:57 <ralonsoh> I don't have anything else in the etherpad backlog (for bugs)
15:39:07 <ralonsoh> Something else?
15:39:13 <mlavalle> not from me
15:39:20 <rubasov> not from me too
15:39:27 <ralonsoh> cool
15:39:38 <ralonsoh> #topic Open Discussion
15:39:39 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1476527 - Adoption of Neutron Classifier API into QoS
15:39:40 <openstack> Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor D.C. (igordcard)
15:39:41 <ralonsoh> davidsha,
15:39:43 <ralonsoh> please
15:39:48 <davidsha> Thanks
15:40:35 <davidsha> We merged the last patch for the Neutron Classifier API 2 weeks back
15:41:45 <davidsha> We originally were aiming to have it adopted into QoS to have targeted traffic tagging fro DSCP and bw limiting, how do people feel about enabling these features now?
15:42:52 <ralonsoh> that means we need to use this extension to classify the traffic
15:42:54 <davidsha> I'm working on some patches at the moment to see what challenges there could be to integrating the features
15:43:12 <mlavalle> are the patches a PoC?
15:43:13 <davidsha> ralonsoh: yes, it would be an optional parameter
15:43:32 <davidsha> mlavalle: at the moment yes, I put some up earlier today
15:43:54 <mlavalle> let's take a look
15:44:00 <davidsha> https://review.openstack.org/#/c/636330/
15:44:00 <patchbot> patch 636330 - neutron-lib - (PoC)Classification field in Neutron DSCP - 2 patch sets
15:44:05 <mlavalle> and go from there
15:44:05 <davidsha> https://review.openstack.org/#/c/636333/1
15:44:05 <patchbot> patch 636333 - neutron - (PoC)Classification field in Neutron DSCP - 1 patch set
15:44:17 <davidsha> https://review.openstack.org/#/c/636336/1
15:44:18 <patchbot> patch 636336 - neutron-classifier - Migrating Classification Groups - 1 patch set
15:44:29 <liuyulong> Just lost my connection, reading the log...
15:44:38 <davidsha> Those are the three main patches, I have a few others for OSC
15:45:44 <ralonsoh> with those patches will be able to shape traffic depending on the DSCP marks
15:46:14 <davidsha> No, with these patches depending on the traffic leaving a port you could assign a DSCP mark to it
15:46:21 <ralonsoh> ok
15:47:07 <davidsha> If I expand on the validation of multiple QoS Rules you could have multiple DSCP marks depending what traffic you want tagged
15:47:41 <ralonsoh> that means you need more than one DSCP rule per QoS policy
15:47:49 <ralonsoh> and per direction
15:48:15 <davidsha> potentially, and there wouldn't be much point tagging traffic coming into the port
15:49:33 <davidsha> But for example if you want IPv4 traffic destined for a certain host to have a certain DSCP mark and all SSH traffic leaving the port to have another that would be a potential use case for have multiple targeted dscp rules.
15:49:56 <ralonsoh> hmmm the potential problem is, only if you have this extension enabled, more than one DSCP rule should be allowed
15:50:20 <ralonsoh> or maybe just a verification to have several DSCP rules, all of them different
15:50:30 <davidsha> I believe the QoS rules have validation to make sure you don't bw limit less than the garuntee right?
15:50:54 <ralonsoh> I think so, I need to check it
15:51:31 <davidsha> You could compare the classification_group_id and if it matches a DSCP rule already in the policy then throw an exception
15:52:47 <davidsha> https://github.com/openstack/neutron/blob/master/neutron/objects/qos/qos_policy_validator.py#L29
15:53:00 <ralonsoh> yes, I was there right now
15:53:07 <ralonsoh> I think you can extend this function
15:53:19 <ralonsoh> not only for BW check
15:54:03 <mlavalle> I have to leave for an internal meeting
15:54:05 <mlavalle> o/
15:54:08 <davidsha> cya!
15:54:10 <ralonsoh> bye
15:54:57 <ralonsoh> davidsha, ok so I think we need to take a look at your PoC patches
15:55:14 <ralonsoh> and deploy to test them
15:55:32 <ralonsoh> but IMO is a good idea
15:55:33 <davidsha> ralonsoh: kk, at the moment they only implement the API side
15:55:49 <ralonsoh> BTW, I don't know if a RFE will be needed, just in case
15:55:50 <davidsha> I'll have the backend driver by next week hopefully
15:56:19 <davidsha> kk, I have an old one from 3 years ago if that sounds appealing ;)
15:56:35 <ralonsoh> hahaha yes now I remember
15:57:24 <ralonsoh> ok, something else to be discussed?
15:58:12 <ralonsoh> thank you all! see you in gerrit!
15:58:20 <davidsha> Thanks! talk to you!
15:58:20 <ralonsoh> #endmeeting