#openstack-meeting log

15:01:44 <ralonsoh> #startmeeting neutron_qos
15:01:45 <openstack> Meeting started Tue Aug  1 15:01:44 2017 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:48 <openstack> The meeting name has been set to 'neutron_qos'
15:01:52 <ralonsoh> Ufff bad command
15:02:04 <ralonsoh> Just for information
15:02:07 <ralonsoh> #link https://etherpad.openstack.org/p/neutron_qos_meeting_chair
15:02:13 <ralonsoh> #topic RFEs
15:02:22 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1578989
15:02:22 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:02:40 <ralonsoh> slaweq, I don't see mlavalle here
15:02:59 <ralonsoh> This spec needs to be re-approved this cycle
15:03:04 <ralonsoh> but we need to work on this
15:03:17 <ralonsoh> Do you mind to wait until the PTG?
15:03:30 <ralonsoh> We can talk to ajo and mlavalle too
15:03:30 <slaweq> 'this cycle' - You mean Queens, right?
15:03:33 <ralonsoh> Yes
15:03:46 <ralonsoh> for queens
15:03:48 <davidsha> Sure.
15:03:50 <slaweq> yes, we should have time to talk about it in Denver
15:04:09 <ralonsoh> perfect, because I need to clarify some aspects of the spec made by ajo
15:04:25 <slaweq> ajo was today on IRC
15:04:31 <ralonsoh> and, finally, we could start coding (the first patch has a +2, but need rebase)
15:04:33 <slaweq> so maybe You will be able to catch him
15:04:39 <ralonsoh> yes, I talked to him
15:04:43 <davidsha> Fixing a Devstack issue if I recall.
15:04:53 <ralonsoh> yes, he will be and he'll have time for this
15:05:14 <ralonsoh> yes, related with the kernel version of centos/rh
15:05:23 <ralonsoh> ok so, this rfe for Denver
15:05:30 <slaweq> ok
15:05:38 <ralonsoh> next, one
15:05:40 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1596611
15:05:40 <openstack> Launchpad bug 1596611 in neutron "[RFE] Create L3 IPs with qos (rate limit)" [Wishlist,Triaged] - Assigned to LIU Yulong (dragon889)
15:05:45 <ralonsoh> 2 patches:
15:05:51 <ralonsoh> #link https://review.openstack.org/#/c/453458/
15:06:10 <ralonsoh> This one is the TC implementation
15:06:22 <ralonsoh> slaweq, davidsha: can you take a look at this one?
15:06:28 <slaweq> sure
15:06:34 <ralonsoh> LIU submitted a new version
15:06:41 <davidsha> ralonsoh: sure
15:06:44 <ralonsoh> As is commented in the patch, I think the code is ok
15:06:45 <ralonsoh> but
15:06:55 <ralonsoh> I don't agree with spliting the TC code
15:07:15 <ralonsoh> second
15:07:15 <ralonsoh> #link https://review.openstack.org/#/c/424466/
15:07:24 <ralonsoh> waiting for my comments
15:07:30 <slaweq> me neighter but I will check it once again
15:07:41 <ralonsoh> but please, if you have time, take a look at this second patch
15:07:55 <ralonsoh> slaweq: you know about adding qos extensions hehehe
15:08:04 <slaweq> yes
15:08:16 <slaweq> I will check it today evening
15:08:23 <ralonsoh> thanks!!
15:08:26 <davidsha> I was looking over the second patch, was wondering should this be an l3 extension but I'll go over it more thoroughly.
15:09:15 <ralonsoh> davidsha: I have this doubt too. But this is going to use the QoS API
15:09:31 <ralonsoh> and needs to be aligned with L2 QoS
15:09:37 <davidsha> ralonsoh: It can use the QoS API and use an l3 extension.
15:10:02 <davidsha> and an L2 extension as well.
15:10:24 <ralonsoh> how?
15:10:55 <davidsha> L2 agent, L3 agent and q-svc all listen on RPC right?
15:11:01 <ralonsoh> yes
15:11:36 <davidsha> Just make an L3 extension for QoS that listens to QoS events.
15:11:56 <davidsha> Same as L2 and only acts on the L3 qos rules.
15:12:45 <ralonsoh> this extension is going to affect only the FIP ports
15:12:55 <ralonsoh> isn't it?
15:12:57 <slaweq> sorry but maybe I don't understand, this patch is about API extension and DB, right?
15:13:06 <ralonsoh> both
15:13:10 <davidsha> Ah, sorry!
15:13:12 <slaweq> so about what L2 and L3 extensions are You talking?
15:13:20 <ralonsoh> FIP qos extension
15:13:41 <slaweq> API extension, yes?
15:14:32 <ralonsoh> davidsha: IMO, the QoS extension (which is in charge of managing the qos rules) should be in charge of managing the qos rules for FIP
15:14:53 <davidsha> I'll go over it again, sorry!
15:15:19 <ralonsoh> and extending fip object
15:15:26 <slaweq> so, You are talking about to which service plugin it should be added as supported extension, right?
15:15:27 <ralonsoh> (BTW, FIP is going to be an OVO)
15:15:36 <ralonsoh> yes
15:15:49 <slaweq> ok, I understand now
15:15:51 <slaweq> thx ralonsoh
15:16:36 <ralonsoh> the point is qos_plugin can attend FIP events
15:16:58 <ralonsoh> and talk to ml2 drivers (send the information to the agents)
15:17:03 <ralonsoh> and modify the qos rules
15:17:29 <slaweq> but what about validation mechanism for FIP?
15:17:41 <slaweq> it is based on vif type
15:17:58 <slaweq> will it work in same way for FIP like for ports now?
15:18:22 <ralonsoh> one sec....
15:19:13 <ralonsoh> ok
15:19:22 <ralonsoh> can we extract the port information from FIP?
15:19:33 <ralonsoh> through the network/subnet
15:19:57 <slaweq> I don't know for now
15:20:00 <davidsha> I'm not sure, this is why I was wondering about L3 extensions, fip is handeled by the l3-agent.
15:20:36 <slaweq> I'm doing "neutron floatingip-show" now on devstack and I don't have port_id
15:20:42 <ralonsoh> davidsha: the same problem: how do you talk to the agent?
15:21:02 <ralonsoh> slaweq: no, you need to talk to the l3 agent to retrieve it
15:21:07 <ralonsoh> davidsha?
15:21:10 <slaweq> ralonsoh: ok
15:21:18 <ralonsoh> can we davidsha?
15:21:34 <slaweq> but then what about supported rules? we have for now drivers only for L2 agents
15:21:36 <ralonsoh> the l3 router has this information
15:21:38 <davidsha> ralonsoh: Adding fip RPC events is the only thing I can think of but I'll need to look into it more.
15:21:55 <davidsha> Listening* to fip rpc events
15:21:55 <slaweq> we should have separate driver for L3 agent to set there what rules are supported by it
15:22:21 <ralonsoh> slaweq: yes, that's the backend implementation
15:22:43 <slaweq> not only because validation of supported rules is done on server
15:22:43 <ralonsoh> slaweq: and you need to have a driver for this
15:23:37 <slaweq> so IMHO we will need something like L2/ovs_driver, L2/linuxbridge_driver (we have it now)
15:23:44 <slaweq> and also new L3/ovs_driver
15:23:50 <ralonsoh> slaweq: yes, that's the point
15:23:51 <davidsha> you need an l3-agent extension in it's entirety to listen for QoS events and then Apply the rules when necessary.
15:23:54 <slaweq> L3/linuxbridge_driver
15:24:04 <ralonsoh> slaweq: Lui was interested "only" in LB
15:24:36 <slaweq> it's fine only for LB for the beginning but we need "base" for that
15:24:57 <davidsha> ralonsoh: If we do this on the L3-agent, there is only 1 backend.
15:24:58 <ralonsoh> davidsha: I think is in the other way. QoS listening to FIP events to add/modify/delete rules
15:25:14 <ralonsoh> davidsha: 1 backend??
15:25:44 <davidsha> It just uses IP lib to configure network namespaces for everything.
15:26:09 <ralonsoh> davidsha: and your implementation of DVR using OF??
15:26:15 <ralonsoh> with OVS
15:26:32 <davidsha> ralonsoh: Yes, I meant right now.
15:26:41 <ralonsoh> davidsha: ok
15:26:55 <ralonsoh> let me put this in the other way: qos extension with l3/LB
15:27:15 <davidsha> kk
15:27:17 <ralonsoh> anyway, the developer is not here and it's not reading this
15:27:19 <slaweq> I agree it should be qos extension
15:28:06 <ralonsoh> if any core has time, I will explain both options and ask for feedback
15:28:24 <ralonsoh> let's move on... agree?
15:28:28 <slaweq> yes
15:28:29 <davidsha> agrred
15:28:32 <ralonsoh> last one
15:28:34 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/1649517
15:28:34 <openstack> Launchpad bug 1649517 in neutron "qos policy attached to network, qos_policy_id is reflecting on neutron net-show , but not on the port with neutron port-show" [Wishlist,In progress] - Assigned to Reedip (reedip-banerjee)
15:28:34 <davidsha> agreed*
15:28:46 <ralonsoh> reedip needs to have this one approved
15:28:59 <slaweq> it's moving forward but slowly
15:29:06 <ralonsoh> and also he needs to take a look at the fails in jenkins
15:29:19 <slaweq> he pushed some new patch so I will take a look on it also
15:29:29 <ralonsoh> I saw it
15:29:34 <ralonsoh> but it's failing
15:29:42 <slaweq> yes
15:29:52 <ralonsoh> I prefer to have something working, the errors are easy to solve
15:30:17 <ralonsoh> "I prefer to have something working" <-- captain obvious!!!
15:30:19 <ralonsoh> hehehehe
15:30:31 <davidsha> :P
15:30:41 <ralonsoh> anyway, I'll leave a comment in the patch
15:30:52 <ralonsoh> to push this rfe in the drivers meeting
15:30:56 <ralonsoh> to be approved
15:31:21 <ralonsoh> no more rfes! next topic
15:31:23 <ralonsoh> #topic Bugs
15:31:27 <ralonsoh> no bugs
15:31:34 <davidsha> Always good.
15:31:36 <slaweq> \o/
15:31:47 <ralonsoh> well, yamamoto is enabling the qos tests
15:32:00 <slaweq> yes, I want to check it more deeply
15:32:04 <ralonsoh> so let's take a look during next days
15:32:14 <slaweq> but it passes for me each time
15:32:17 <ralonsoh> I know, you are doing a fantastic work in testing
15:32:20 <ralonsoh> thanks slaweq
15:32:27 <slaweq> thanks :)
15:32:45 <davidsha> Thanks slaweq
15:32:52 <ralonsoh> next topic??
15:32:55 <slaweq> we also made some small changes (not directly in QoS) to make qos working with py35
15:33:03 <slaweq> it's just FYI
15:33:06 <ralonsoh> can you send the patch?
15:33:17 <slaweq> patch was for oslo
15:33:23 <slaweq> give me 1 second
15:34:35 <slaweq> https://bugs.launchpad.net/neutron/+bug/1701202
15:34:35 <openstack> Launchpad bug 1701202 in neutron "Create QoS rule fails on python 3.5" [Undecided,Fix released] - Assigned to Slawek Kaplonski (slaweq)
15:34:38 <slaweq> this was this bug
15:34:44 <slaweq> and it should be fixed already
15:34:51 <ralonsoh> yes, now I remember
15:34:55 <ralonsoh> I closed this bug today
15:35:00 <ralonsoh> perfect!!
15:35:11 <slaweq> now all QoS related fullstack tests are passing on py35
15:35:20 <davidsha> \o/
15:35:28 <ralonsoh> that's great
15:35:43 <ralonsoh> let's move on
15:35:44 <ralonsoh> #topic Other Changes
15:36:00 <ralonsoh> I have in the cheat sheet
15:36:01 <ralonsoh> "Ask slaweq infra-shade patch"
15:36:23 <slaweq> I started adding support for QoS in openstack-shade client
15:36:32 <slaweq> it's almost done
15:36:36 <ralonsoh> I saw this
15:36:41 <ralonsoh> An I think the code is ok
15:36:45 <slaweq> I'm still missing min bw rules
15:36:54 <slaweq> and this new call with supported rule details
15:37:17 <ralonsoh> yes, very nice
15:37:20 <ralonsoh> one question
15:37:21 <slaweq> later I will have to add some functional tests for all of it also
15:37:27 <slaweq> yes ralonsoh?
15:37:39 <ralonsoh> you don't test if a call is made without one needed parameter
15:37:45 <ralonsoh> for example, missing min_bw
15:38:12 <slaweq> that's good point
15:38:26 <slaweq> I will check it and maybe also fix it for bw limit also
15:38:40 <ralonsoh> I don't have experience on this project, but when I took a look I missed that
15:38:46 <ralonsoh> just for info hehehe
15:39:09 <ralonsoh> I think that's all folks
15:39:15 <ralonsoh> anything else?
15:39:18 <slaweq> yes, I will add such checks also
15:39:20 <slaweq> thx
15:39:29 <slaweq> I have one question to davidsha
15:39:33 <davidsha> slaweq: sure
15:39:49 <slaweq> can You check https://review.openstack.org/#/c/483817/ as native speaker? :)
15:40:40 <davidsha> slaweq: Sure!
15:40:43 <slaweq> thx
15:40:53 <ralonsoh> hahaha I "use" davidsha for the same porpuse some times hahahahaha
15:40:54 <slaweq> that's all for me
15:41:01 <slaweq> :)
15:41:11 <davidsha> :P
15:41:16 <ralonsoh> thanks davidsha, slaweq!
15:41:22 <davidsha> Thanks!
15:41:27 <ralonsoh> #endmeeting