14:07:22 #startmeeting neutron_qos 14:07:23 Meeting started Wed Sep 9 14:07:22 2015 UTC and is due to finish in 60 minutes. The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:07:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:07:27 The meeting name has been set to 'neutron_qos' 14:07:48 Ok, this is an small meeting to look at a couple of topics going forward with QoS 14:08:03 #topic nova-neutron integration 14:08:09 johnthetubaguy, are you around? 14:08:17 I want to loop in more nova people for the next meeting 14:08:28 I will send an email for next week 14:08:43 irenab, had proposed referencing qos policies from nova flavours 14:09:09 but johnthetubaguy was expressing his concern on #neutron channel this morning, that may be that's not the best way to do it. 14:09:18 hi 14:09:27 He was talking about something called vif flavours, but I'm not aware of how that works, or where is it supposed to live 14:09:47 ajo: it was raised about 2 years ago when started with sr-iov support 14:10:17 it makes sense to me 14:10:25 it can be better approach, but not sure how this can be done without changing nova 14:10:40 he had this concern on the irc today 14:10:51 ok, we just need to work together with the nova team to find the best way to do it 14:11:04 not sure if I understood from johnthetubaguy comments that vif plugging code was going to be passed to neutron too 14:11:09 maybe he meant for future once nova supports nic flavors any new flavor support will be transaprent 14:11:11 but still 14:11:19 I believe we should associate that to the flavors somehow 14:11:39 ajo: great, lets have discussion with nova guys 14:11:41 so CSPs are able to provide different levels of service for network from one point 14:11:52 ok, I will raise the question on the mail list. 14:12:03 and invite them to the next meeting, if it works for them 14:12:25 irenab, anything more on this topic? 14:12:46 not as far as I know 14:12:52 ok 14:12:55 ajo: linuxbridge changes done for qos? 14:13:26 Ramanjaneya, no, as far as I undertood vikram/your team will look at it for M 14:13:29 I also wanted to ask about status of DCSP marking support 14:13:42 I believe it's healthy to get it done 14:13:50 Ok 14:13:55 1 sec, I was going to raise another nova topic 14:14:05 #topic neutron-nova integration: QoS guarantees 14:14:21 we need also some sort of nova awareness on our QoS policies 14:14:39 to make sure min-bandwidth hard rules won't result in overcommit on the compute nodes 14:15:06 or in the compute nodes network adapters (whem thinking of VFs over PFs) 14:15:11 whem->when 14:15:34 ajo: are you talking about networking aware scheduling? 14:15:47 yes, there are two pieces there 14:15:49 or get it from nova? 14:16:06 one is , general scheduling (from nova) to decide where to put an instance (which compute node) based on available BW 14:16:39 and another is lower lever scheduling, for SR-IOV, if you have several PFs (ports) on a card, not to put all VFs on the same one, regardless of the limits 14:17:10 We need to agree on that part too, and how to do it 14:17:24 otherwise we cannot provide anything beyond "best effort" min bandwidth 14:17:36 (in ovs at least) 14:18:11 irenab, any thought? 14:18:34 need to think about at… 14:18:39 or should we move on?, I just wanted to make the idea available in the meeting log at least :) 14:19:04 ajo: I guess we need nova guys for this as well 14:19:05 #topic other rules, prioritizing 14:19:19 yes, let's talk all together 14:19:27 irenab: you pointed out DSCP, 14:19:46 that's been long awaited, I guess vhoward and his team are on top of it for M 14:19:54 * irenab having meeting conflict, will try to follow.. 14:19:59 ack, thanks irenab 14:20:23 ajo: thank you for update on dcsp 14:20:24 vikram: we could also thing of TC if the traffic classification API gets done early M 14:20:35 ajo: +1 14:20:41 ajo: +1 14:20:43 irenab: :) 14:20:50 thing -> think :) 14:20:55 I can also learn how to type.. 14:20:58 ajo: We need to get the spec approved first 14:21:07 vikram, it's quite there I think :) 14:21:16 lots of parts depending on it :) 14:21:20 also 14:21:36 I also want it to be done 14:21:49 we will have to resolve how we allow rules in mixed environments (sr-iov + ovs, or +lb) 14:21:50 Let's freeze it ASAP 14:22:10 because SR-IOV will only allow BW limiting AFAIK 14:22:44 ajo: so what about UPGRADE? I don't think new rules are allowed in before it's done 14:22:52 so, may be we can discriminate setting rules by vnic type when attaching to a port 14:22:55 ihrachys: yes 14:22:59 I was about to get to that point 14:23:03 UPGRADEs!, 14:23:05 ajo: I have few open question about the spec.. We can discuss offline 14:23:14 I will be the first one to minus vote until then. no discussion of new rules is fruitful before foundation is set 14:23:17 we will need to make the rpc callback mechanism capable of handling upgrades 14:23:49 let's not block rule prioritization, I assume we're capable of upgrading with RPC in place :) 14:24:04 that's just a technical detail 14:24:05 what do you mean? 14:24:16 well ok but upgrade should be fixed before new rules in 14:24:23 that for sure :) 14:24:26 I don't care how we track it 14:24:40 ok, we are on the same page, I ranted 14:24:41 I mean, we can discuss which rules we want to prioritize, but of course, we can't introduce new ones until upgrading is in place. 14:24:47 :-) 14:24:58 ihrachys: I had an idea for that (doing it automatic) 14:25:11 I just want everyone to understand the limitation so that there are no questions why it's not in 14:25:22 we could leverage the agent status updates, to inform which versioned objects they exactly support 14:25:44 so... no report of that: neutron-sever assumes it needs to send older versions... 14:25:48 (first version) 14:26:04 ajo: for all types? or some of them? 14:26:26 what if agent hits server before reported new versions? 14:26:45 do we forbid such hit until report? how? (reports are casts, right?) 14:27:18 agent -> server comm always asks for specific verions 14:27:19 anyway, I don't think it's so easy. we need write-up and discussion. 14:27:20 versions 14:27:22 so that's safe 14:27:26 true 14:27:47 it's server->agent fanouts what needs to be duplicated per agent supported versions 14:28:01 yes 14:28:06 it needs discussion I guess 14:28:10 I'm sure it's not flawless 14:28:22 right. so how do we guarantee agent does not subscribe before report is successfully registered on server side? 14:28:38 it's rhetoric question 14:28:43 let's move on 14:28:57 yeah, that's one of the flaws I'm seeing ;) 14:29:28 may be we need to pin for 1 release, and then set something automatic to make sure agent reports (and blocks) until subscription 14:29:35 via an independent api call 14:29:37 we will see 14:29:42 ----- 14:29:54 ok, any other topics you'd like to raise? 14:30:30 3, 2, 1 ... ;) 14:30:54 vikram, ihrachys , irenab , moshele, thanks! 14:31:06 ajo: wc 14:31:11 wc? :) 14:31:18 welcome 14:31:33 :D 14:31:36 #endmeeting