14:08:10 <ajo> #startmeeting neutron_qos 14:08:11 <openstack> Meeting started Wed Jan 27 14:08:10 2016 UTC and is due to finish in 60 minutes. The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:08:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:08:15 <openstack> The meeting name has been set to 'neutron_qos' 14:08:21 <ajo> Hi everyone :-) 14:08:31 <ihrachys> howdy 14:08:41 <irenab> hi 14:08:47 <ajo> #link https://etherpad.openstack.org/p/qos-mitaka The usual etherpad-agenda 14:09:31 <ajo> Last meeting was a bit lonely, due to strange things with ics, or human error and misleading from my side :) 14:10:26 <ajo> We had a couple of things merged since last meeting 14:10:43 <ajo> RBAC spec: https://review.openstack.org/#/c/254224/ .. yey hdaniel ! 14:10:52 <hdaniel> :)) 14:10:54 <ajo> and Validation for ml2 extension driver to be enabled when qos service plugin is used with the plugin: https://review.openstack.org/#/c/253853/ 14:11:10 <ajo> yes slawek, probably more QoS related stuff was merged, 14:11:59 <ihrachys> prolly. let's not celebrate for too long look at stuff NOT merged :) 14:12:10 <ihrachys> *and look 14:12:12 <ajo> :) 14:12:24 <ajo> yep 14:12:31 <ajo> #topic Tracking items 14:12:46 <ajo> If somebody dares to call me optimist, will be right. I'm still working in the RPC callback rolling upgrade core logic: https://review.openstack.org/#/c/265347/ 14:13:23 <ajo> I was working on another patch right now, and I will continue after meeting, it looks considerable well, thanks ihrachys for the reviews 14:13:46 <reedip_> ajo : Hello 14:13:59 <ajo> hi reedip_ welcome 14:14:05 <ihrachys> I think we should be almost there with it; as long as tests are ready. 14:14:23 <ihrachys> honestly, I was not checking those since it seemed to me we should shake API first. 14:14:38 <ajo> ihrachys, yes, I think my current testing is reasonable, but I'm the writer, probably I must do an extra pass and verify I'm not missing stuff 14:15:02 <ajo> ihrachys, ack, let's get into testing afterwards 14:15:38 <ajo> also, I mush push a second patch for integration with the agent, adding some db migrations, I have a version locally for that which I haven't updated lately, now it's out of sync with the core logic api 14:16:04 <ihrachys> I suggest we get the first piece in, then care about the 2nd one 14:16:28 <ajo> yes, this is why I'm not updating the 2nd part patches without the 1st part being ready, it's too much rework every time 14:16:35 <ihrachys> righ 14:16:37 <ihrachys> *right 14:16:37 <ajo> wasted work 14:16:53 <ajo> ok, so let's keep that rolling, and going forward, 14:17:26 <ajo> as a note, when this (https://review.openstack.org/#/c/268040/1) is ready, the DSCP patches will need to be rebased on top of it 14:17:34 <ajo> but now that breaks the world, 14:17:49 <ajo> and it's quite far from my local version 14:17:54 <ihrachys> ajo: it's already based on l2-agent-extensions patch, I bet we don't want to have too deps 14:18:06 <ihrachys> *two deps 14:18:42 <ajo> right 14:18:56 <ajo> ok, they probably don't need the dept 14:19:18 <ajo> or to rebase on top of mine, as long as it's not merged until rpc callbacks upgrade support is merged 14:19:20 <ihrachys> we'll manage the order manually 14:19:27 <ajo> agreed 14:19:41 <ihrachys> not that there are people pushing the patch apart from us :) 14:20:14 <ajo> ihrachys: can we use the Depends-On for that? 14:20:25 <ajo> ihrachys, will the gate check the dependency is merged before ? 14:20:54 <ihrachys> ajo: we can, in theory. but I would keep test failures separate 14:21:05 <ihrachys> ajo: if you depends-on, you get all failures from all patches 14:21:20 <ajo> aha 14:21:24 <ajo> ok 14:21:45 <ihrachys> and honestly, I would not be bothered by dscp piece right now until we get the deps in. the deps are the blockers that concern me a lot. 14:22:21 <ajo> ok, let's try to move the upgrades quicker, 14:22:34 <ajo> ok, next topic then 14:22:44 <ajo> #topic RBAC status 14:23:01 <ajo> hdaniel, could you update about RBAC integration status? :) 14:23:05 <hdaniel> sure 14:23:28 <hdaniel> the patch is rewritten - to be used in a more "magical" way 14:23:33 <slaweq> hello 14:23:54 <hdaniel> per ihrachys suggestion - I've added metaclass to inject the functionality 14:24:05 <hdaniel> will push first wip patch today. 14:24:12 <ihrachys> nice 14:24:25 <hdaniel> wait, till you see it , 14:24:29 <hdaniel> :) 14:24:32 <ihrachys> lol 14:24:34 <ajo> lol 14:24:38 <ihrachys> ok let's see it first indeed :D 14:24:53 <hdaniel> the client's patch needs to be rebased too, but I didn't have the time yet 14:25:09 <ajo> I must admit, magical sounds good and worrying ;D 14:25:18 <ajo> for example, mixins could seem magical at first sight 14:25:33 <ajo> so, let's see it :D 14:25:46 <hdaniel> mixins are like mushrooms - they are magical, but there's a price to pay .. 14:25:54 <ajo> lol 14:26:08 <hdaniel> ok, so I'm pretty sure I'll push the WIP draft today 14:26:21 <ihrachys> sounds reassuring :) 14:26:24 <ajo> thanks hdaniel :) 14:26:37 <ajo> ok, next topic 14:26:46 <ajo> #topic Linux bridge integration 14:26:57 <ajo> slaweq, the stage is yours 14:27:08 <slaweq> ok, so 14:27:21 <slaweq> my patch for qos in linuxbridge is (I hope) almost ready 14:27:29 <slaweq> most reviewers gave "+1" for this 14:27:32 <ihrachys> it was pretty clean the last time I checked, yes 14:27:41 <slaweq> I have to update some docs and release notes to it 14:27:51 <ihrachys> we need fullstack, that's the concern now I guess 14:27:53 <slaweq> but I'm still fighting with this fullstack tests support 14:28:05 <ihrachys> have you tried to add rootwrap filters as I suggested before? 14:28:16 <slaweq> that is not so easy for linuxbridge (I'm testing connectivity there) 14:28:23 <slaweq> ihrachys: not yet 14:28:37 <slaweq> I'm in business trip this week and I have not too much time to do this 14:28:51 <slaweq> but I hope to do it today or tomorow 14:29:04 <ihrachys> that's fine. note that I will be pretty much off the next week. 14:29:17 <slaweq> FYI: fullstack test for connectivity is passing for me with linuxbridge but when I run it as root 14:29:36 <slaweq> when I run it as normal user that linuxbrigde agent is not spawning properly 14:29:44 <slaweq> and test is failing 14:29:54 <ajo> slaweq, looks like the root wrap filters for fullstack then 14:29:59 <ihrachys> ...and we suspect it may be missing IpNetNs rootwrap filter for lb agent 14:30:08 <slaweq> so I have to solve this issue and do some (big) refactoring to address all coments from reviewers 14:30:29 <slaweq> ajo, ihrachys: yes, it looks like that :) 14:30:31 <ihrachys> slaweq: pay special attention to John's comments, he is our fullstack guru :) 14:30:47 <slaweq> but I have to check it and check where I should configure rootwrap rules for tests 14:31:03 <slaweq> I know where to add it for "normal" working scripts but not for tests 14:31:31 <ihrachys> right. I think you need to run deploy_rootwrap.sh as part of fullstack target 14:31:38 <ihrachys> as we do for functional target 14:32:01 <slaweq> ok, thx for tips ihrachys 14:32:04 <ihrachys> ok, I guess we have a plan here. 14:32:11 <ihrachys> let's move on 14:32:13 <slaweq> so generally it is all about linuxbridge 14:32:23 <ajo> thanks slaweq and ihrachys :) 14:32:29 <ajo> #topic DSCP markings 14:32:42 <ajo> njohnston, vhoward , any update on the topic? 14:33:14 <ihrachys> I need to admit I haven't looked into the code lately. was spending time on reviews for ajo and David for l2-agent-extensions. 14:33:25 <ajo> yes, I was going to point that out 14:33:34 <ajo> #link https://review.openstack.org/#/c/267591/ 14:33:43 <ihrachys> right, that one 14:33:57 <ajo> and 14:33:58 <ihrachys> I think we are mostly ok with API part, just need testing coverage 14:33:59 <ajo> #link https://review.openstack.org/265347 14:34:01 <ihrachys> "just" 14:34:05 <ajo> ok 14:34:17 <ajo> is David around? 14:34:24 <ihrachys> davidsha: 14:34:38 <ajo> davidsha, ping :) 14:35:21 <davidsha> Hi, sorry 14:35:50 <ajo> I'd loop yamamoto and ann to check the patch :) 14:35:56 <davidsha> Nate said he was working on tests for the l2-agent 14:36:22 <davidsha> I'm working my way through the comments. 14:37:16 <ihrachys> oh nice that you do stuff in parallel. :) 14:37:22 <davidsha> :) 14:37:46 <ihrachys> I try to get back to the patch every day, hopefully I down slow down it 14:37:55 <ihrachys> ajo: ok, I will add them. 14:38:08 <ajo> I have pinged yamamoto_, akamyshnikova on irc, but cannot find Ann's email 14:38:16 <ajo> ihrachys, : thanks 14:38:39 <ajo> ok, 14:38:46 <ajo> #topic Open discussion 14:38:58 <ajo> anybody want's to raise any other topic or important bug? 14:39:02 * ajo looks at the bug list 14:39:05 <reedip_> ajo : pimg 14:39:11 <reedip_> ping* 14:39:23 <ajo> hi reedip, go ahead :) 14:39:23 <ihrachys> I just want to say we need more reviews on our patches in general 14:39:24 <irenab> ajo: any update on scheduling part? 14:39:51 <ihrachys> oh scheduling... I saw today the spec was -1'd 14:40:00 <ihrachys> due to some parallel effort from inside nova 14:40:04 <ajo> ihrachys: yes, probably I should be spending my time more in QoS patches instead of other stuff 14:40:10 <vikram> ajo: can you plz help approving https://bugs.launchpad.net/neutron/+bug/1505631 14:40:11 <openstack> Launchpad bug 1505631 in neutron "QoS VLAN 802.1p Support" [Wishlist,New] - Assigned to Reedip (reedip-banerjee) 14:40:41 <ihrachys> vikram: it will be discussed on next drivers meeting 14:40:48 <ajo> ihrachys, : true, I need to look at the other approach, I looked at it once a month ago, and it didn't look like compatible with what we wanted to do, but may be it's able to model our problem and I just didn't get it 14:40:51 <ihrachys> on one of next meetings ;) 14:40:52 <vikram> ihrachys: thanks 14:41:02 <irenab> ajo: the neutron side RFE for reporitng actual bw was rejected 14:41:17 <ajo> vikram, , correct, it has the same RPC callback upgrade support dependency as DSCP does, 14:41:24 <ihrachys> ajo: yeah, we should clarify that with nova folks before they get too far in their implementation 14:41:25 <vikram> ajo: yup 14:41:48 <reedip_> wow , open discussion indeed :) 14:41:53 <ihrachys> irenab: I think it was sort of 'postponed' 14:41:57 <ajo> irenab, yes, as ihrachys said, we need to clarify who pushes that, and how 14:42:02 <ihrachys> just because we are not sure how scheduler will work 14:42:08 <reedip_> ajo: I just wanted to share about https://bugs.launchpad.net/neutron/+bug/1505627 14:42:09 <openstack> Launchpad bug 1505627 in neutron "QoS Explicit Congestion Notification (ECN) Support" [Wishlist,New] - Assigned to Reedip (reedip-banerjee) 14:42:09 <ajo> if it's going to be the agents, we don't need centralised reporting to neutron-server 14:42:09 <irenab> ajo: ihrachys agreed 14:42:35 <ajo> if somebody has some time to analyze again the other nova spec 14:42:37 <ajo> it would be great 14:42:44 <ajo> I have not enough bandwidth currently :( 14:43:06 <ajo> #link https://review.openstack.org/#/c/253187/ resource-providers: generic resource pools 14:43:21 <ajo> may be every host can be a resource pool... 14:43:24 <ihrachys> irenab: are you up for the challenge? :) 14:43:45 <ajo> but then , we'd have to see how to integrate us updating the resource pool details... I almost don't remember 14:43:51 <irenab> ihrachys: I am afraid I am over my BW currently 14:43:52 <ajo> may be jaypipes is up and around ;) 14:44:25 <ihrachys> that's sad 14:44:38 <ihrachys> well, we'll get to it some time 14:44:48 <ihrachys> ajo: should we have some todo in etherpad? 14:45:06 <ajo> reedip_, vikram we may look at that when we have bandwidth: but please, move this https://beta.etherpad.org/p/Notepad to etherpad.openstack.org 14:45:14 <ajo> beta.etherpad.org can be eventually deleted 14:45:19 <ajo> it's just a demo 14:45:26 <reedip_> ajo : ok, in a minute 14:46:04 <ajo> ihrachys, isn't that the track items? 14:46:13 <ajo> ihrachys, slow moving are the ones unnatended 14:46:24 <ihrachys> ajo: yeah, but it's like a general scheduler thing. we need some details like the link to the alternative spec 14:46:52 <ihrachys> oh sorry, I see it's ther 14:46:54 <ihrachys> *there 14:47:09 <reedip_> ajo, vikram, ihrachys: https://etherpad.openstack.org/p/QoS_ECN 14:47:13 <ajo> ihrachys, np, making it more clear 14:47:52 <ihrachys> ok, that's fine now 14:48:18 <ajo> thanks reedip_, link it to the bug so it doesn't get lost 14:48:26 <reedip_> already done ajo 14:49:51 <ajo> ok 14:49:55 <ajo> anything else ? 14:50:11 <ajo> or shall we do the farewell dance ? :) 14:50:15 * ihrachys dances 14:50:22 <irenab> :-) 14:50:25 <ajo> lol :) 14:50:30 <reedip_> lol 14:50:43 <jaypipes> ajo: I'm in the Nova mid-cycle... 14:50:50 <jaypipes> ajo: how can I help you? 14:50:54 <ajo> hi, jaypipes :) 14:51:05 <ajo> ok, let's not end the meeting, we have 10 more minutes 14:51:15 <ajo> we were talking about your spec: https://review.openstack.org/#/c/253187/ 14:51:32 <ajo> and we wonder if we could use your model to track available bandwidth in hosts 14:51:42 <ihrachys> track and decide on 14:51:57 <ajo> yes, and decide on, for instance scheduling purposes 14:52:13 <ajo> jaypipes, ^ 14:52:35 <jaypipes> ajo: yes, I am almost done with the next revision which has a description of the use case of routed networks in Neutron and using generic resource pools in Nova to give the cloud user ability to specify a port and have Nova able to understand that that port is in a particular subnet, which is attached to a particular segment and that segment is attached to a rack of compute nodes. 14:53:10 <jaypipes> ajo: oh... bandwidth... 14:53:19 <ajo> jaypipes, ok, that's related, and probably more detailed the our intent 14:53:24 <jaypipes> ajo: sorry, that wasn't the use case I talked abotu with Carl. 14:53:35 <ajo> jaypipes, correct, it's something differnt 14:53:45 <ajo> our intent was to track available bandwidth on hosts 14:53:54 <ajo> towards providing bandwidth guarantees to instance ports 14:53:59 <ihrachys> yeah, Carl cares about L3, but here we have QoS case. 14:54:01 <jaypipes> ajo: the problem with QoS and bandwidth is that unlike other resources, bandwidth is an entirely transient thing. it changes from minute to minute. 14:54:19 <ajo> jaypipes, not for guarantees 14:54:40 <ajo> jaypipes, for guarantees you need to know the total host bandwidth (ingress & egress) over each specific physical network 14:54:52 <jaypipes> ajo: it's not a quantifiable resource, though... it's a qualitative assertion about something.. more of a capability than a resource. 14:55:04 <ajo> and then, it's left to the underlaying technology, to make sure the bandwidth limits and guarantees are kept within limits 14:55:09 <ajo> the important constraint is 14:55:41 <ajo> on a physical network: sum(port[i].guaranteed_bw) < total_bw on that physnet 14:55:48 <ajo> for an specific host 14:56:22 <ajo> the idea is that no instance would be scheduled to that host, if it's using a port with an specific bw requirement, that we won't be able to guarantee 14:56:31 <jaypipes> ajo: what is the difference between "guaranteed bw" and normal bw? 14:56:38 <ajo> because we'd be overcommitting the host 14:57:04 <ajo> jaypipes, : the idea of the guarantee is that 14:57:18 <ajo> you provide a minimum bandwidth for a port (instead of a maximum) 14:57:18 <jaypipes> ajo: no, sorry, lemme rephrase my question... 14:57:45 <ajo> so, in any case, if the port is trying to use that bandwidth, (or more) it's packets are sent first 14:57:53 <ajo> then the packets of ports with no guarantees are sent 14:58:13 <ajo> or the packets of ports with lower guarantees (or already sending over it's minimum bandwidth guarantee) 14:58:40 <jaypipes> ajo: if a port has 100 total bw capacity, and 10 instances are given 10 guaranteed bw units each, is there some other process (not an instance, or some privileged thing?) that can consume bandwidth on that port and essentially overcommit the port to more bandwidth than SUM(port[i].guaranteed_bw)? 14:58:44 <ajo> there are a few ways to do it, but basically it's based on queues and packet prioritisation 14:59:07 <ihrachys> the assumption here of course is that underlying infra is capable to handle any bandwidth from any compute node 14:59:13 <ajo> jaypipes, if the guaranteed ports and not using the traffic, the unguaranteed can use it 14:59:21 <ajo> ihrachys, correct 14:59:35 <ajo> that's another level of complexity I don't feel capable of tackling yet 14:59:38 <ihrachys> jaypipes: well, it does not require ideal fit, it's best effort 14:59:47 <ajo> correct, 15:00:00 <jaypipes> ajo, ihrachys: so I think the current modeling of generic resource pools will be able to meet these needs. 15:00:19 <ajo> jaypipes, thanks for the feedback, I will re-read your spec as soon as I can 15:00:21 <ihrachys> cool with me :) 15:00:24 <jaypipes> ajo, ihrachys: or at least the latest (almost ready to be uploaded) patch's model will meet those needs ;) 15:00:25 <ajo> an try to fit our needs with your model 15:00:33 <ihrachys> we need to consider the case, that's all we are asking :) 15:00:39 <jaypipes> yup, of course. 15:00:45 <ajo> thanks a lot :) 15:00:50 <ajo> I'm ending the meeting 15:00:51 <ihrachys> thanks a lot for replying! 15:00:56 <ajo> #endmeeting