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