14:01:07 <ajo> #startmeeting neutron_qos
14:01:08 <openstack> Meeting started Wed Apr 20 14:01:07 2016 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:13 <openstack> The meeting name has been set to 'neutron_qos'
14:02:19 <njohnston> Participating from my car today
14:02:44 <slaweq_> njohnston: and You are driving now? :)
14:02:51 <ajo> hi njohnston
14:02:51 <RP_> nope
14:02:52 <ajo> :-)
14:03:16 <ajo> I was letting some extra time for people to join.
14:03:21 <irenab> hi
14:03:25 <ajo> but it seems that the attendance is low :-),
14:03:49 <RP_> hi
14:03:51 <ajo> njohnston, prepared the agenda for today, as he's stepped in to help me co-chair this meeting
14:03:59 <ajo> and today, he's travelling.
14:04:07 <ajo> thanks njohnston
14:04:23 <ajo> hi RP_ , slaweq_ , irenab , njohnston , so let's begin
14:04:42 <ajo> #topic Summit Planning
14:04:58 <ajo> We have two QoS talks on the schedule, for those interested:
14:05:09 <ajo> #link https://www.openstack.org/summit/austin-2016/summit-schedule/events/7495
14:05:48 <ajo> a general one about Quality of Service, what we accomplished in Mitaka, and the future roadmap, ( slaweq_ , vhoward and me)
14:05:50 <davidsha> #link https://www.openstack.org/summit/austin-2016/summit-schedule/events/7441?goback=1
14:06:10 <ajo> and exactly thanks davidsha
14:06:23 <ajo> an specific one about DSCP
14:06:52 <ajo> njohnston, amd davidsha will be on stage :)
14:07:26 <ajo> We'd also like to announce, if that sounds right, that we'd be cancelling the meeting after the summit, on May 4th.
14:07:29 <njohnston> Yay!
14:07:34 <ajo> hehe njohnston
14:07:44 <vhoward> +1
14:07:46 <davidsha> +1
14:07:49 <ajo> any objections for cancelling the next meeting?  :)
14:07:52 <ajo> +1 from me too
14:07:52 <vhoward> davidsha: haha
14:08:19 <irenab> :-)
14:09:08 <ajo> Also, we should use the friday time to meet, discuss and plan about QoS in person.
14:09:25 <ajo> some of the friday time, :)
14:09:52 <davidsha> ajo: there is also the flow management/ flow classifier meeting on Tuesday with Cathy I believe.
14:10:00 <njohnston> +1
14:10:13 <ajo> oh, great davidsha , what time's that on Tuesday exactly?
14:10:16 <irenab> davidsha: any specific time?
14:10:26 <slaweq_> ajo: can it be friday morning, because I have plane at afternoon?
14:10:30 <davidsha> 1 sec
14:10:38 <ajo> It's an interesting morning.
14:10:53 <ajo> slaweq_ +1 for the morning, most people will be flying on the afternoon I suspect
14:11:00 <slaweq_> ok, great :)
14:11:11 <davidsha> No time "I am thinking about around lunch time on Tuesday or Wednesday since some of us will fly back on Friday morning/noon."
14:11:19 <ajo> I booked my flight back on saturday, because the latest flight was taking off at 18:05 for me
14:11:24 <vhoward> i'm in for friday
14:11:32 <davidsha> -_- lunch time.
14:11:33 <slaweq_> I will go this at 18:05 :)
14:12:01 <ajo> davidsha, may be we should bring a big sign for lunch, it's hard to meet anyone on purpose during summit on lunch
14:12:11 <davidsha> I'll be around on Friday.
14:12:39 <ajo> davidsha, or make the meeting of Tuesday more specific as we see the place on Monday, otherwise I'm afraid the meeting won't really happen
14:13:18 <ajo> ok, let's follow up about that with Cathy on that
14:13:31 <irenab> ajo: can you please share some details regarding scheduler and neutron discussion you emailed few mins ago?
14:13:35 <ajo> and let's talk QoS on friday morning.
14:13:44 <ajo> irenab, sure, there's a point for it.
14:13:57 <ajo> let's follow njohnston's prepared agenda. :)
14:14:18 <ajo> https://etherpad.openstack.org/p/neutron_qos_meeting_chair if you want to sneak peak
14:14:33 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1563720
14:14:33 <openstack> Launchpad bug 1563720 in neutron "Bandwidth limiting for linuxbridge agent works for ingress traffic instead of egress" [High,Fix released] - Assigned to Slawek Kaplonski (slaweq)
14:14:58 <ajo> slaweq_, how's that looking ?
14:15:05 <slaweq_> it's fixed
14:15:24 <slaweq_> we changed tc to use ingress policing instead of shaping egress traffic
14:15:26 <ajo> oh, true, it was merged, /me feels dumb :D
14:15:35 <ajo> good work slaweq_ ,
14:15:41 <slaweq_> in fact it's now in exactly same way like ovs is doing it
14:15:51 <slaweq_> there is also cherry-pick to mitaka of this patch
14:15:55 <slaweq_> waiting for review
14:16:00 <ajo> in the context of that, slaweq_ found that ovs ingress policing burst parameter set's the wrong thing
14:16:17 <ajo> if you ask openvswitch to set 1Mbit burst on a port for ingress policing
14:16:22 <ajo> you get 8Mbit burst
14:16:28 <ajo> (bits mixed with bytes)
14:16:38 <slaweq_> yep, and ajo fixed it in ovs :)
14:16:45 <ajo> I've proposed a fix for ovs,
14:17:01 <ajo> but the issue with that, is that next versions of ovs will behave differently to current ones,
14:17:08 <ajo> we may need to add a flag to the agent, and a sanity check
14:17:19 <ajo> to do the /8 division
14:17:30 <ajo> ok
14:17:31 <ajo> #
14:17:32 <ajo> #link https://launchpad.net/bugs/1486607
14:17:33 <openstack> Launchpad bug 1486607 in neutron "tenants seem like they were able to detach admin enforced QoS policies from ports or networks" [Medium,In progress] - Assigned to Nate Johnston (nate-johnston)
14:17:36 <slaweq_> maybe we should do in ovs something like in LB agent?
14:17:50 <slaweq_> to add burst value as 80% of bw_limit if it is not set?
14:17:59 <ajo> slaweq_, I agree, that's right
14:18:23 <slaweq_> AFAIR ovs sets always 1000kb if burst is not given
14:18:30 <ajo> slaweq_, could you open a bug for it so  we don't forget ?
14:18:35 <slaweq_> but we could make it more consistent for both
14:18:41 <slaweq_> ok, I will
14:18:57 <ajo> yes, I'd set 80% of max_rate by default, of nothing provided
14:19:14 <ajo> thanks slaweq_
14:19:22 <ajo> about the above bug ^
14:19:33 <ajo> njohnston, is on it, he's sorting out the testing details
14:19:37 <ajo> but other than that it should be good.
14:19:57 <ajo> Thanks njohnston!, anything to be noted about it?
14:20:42 <ajo> ok, next one :)
14:20:44 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1568400
14:20:46 <openstack> Launchpad bug 1568400 in neutron "Pecan does not route to QoS extension" [Medium,In progress] - Assigned to Brandon Logan (brandon-logan)
14:20:54 <njohnston> Just that I need to sort out how to take admin and non-admin actions in the same test
14:21:25 <ajo> njohnston, ack, exactly, the testing details, he needs to be able to do operations in the api-tempest tests as admin, and normal tenant
14:21:41 <ajo> if anybody has experience with that ping njohnston, please :)
14:22:01 <ajo> about 1568400 blogan fixed that, it's an issue in the context of pecan, so thanks blogan! :)
14:22:32 <ajo> I will skip " https://bugs.launchpad.net/neutron/+bug/1507654" since ihar doesn't seem around,
14:22:34 <openstack> Launchpad bug 1507654 in neutron "Use VersionedObjectSerializer for RPC push/pull interfaces" [Low,In progress] - Assigned to Artur Korzeniewski (artur-korzeniewski)
14:23:13 <ajo> that seems to be "In progress" but there's no link to the actual patch
14:23:34 <ajo> #action iharchys  link https://bugs.launchpad.net/neutron/+bug/1507654 to the gerrit review
14:23:35 <openstack> Launchpad bug 1507654 in neutron "Use VersionedObjectSerializer for RPC push/pull interfaces" [Low,In progress] - Assigned to Artur Korzeniewski (artur-korzeniewski)
14:23:49 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1507761
14:23:50 <openstack> Launchpad bug 1507761 in neutron "qos wrong units in max-burst-kbps option (per-second is wrong)" [Low,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:23:53 <ajo> slaweq_, this one is yours ^
14:23:56 <slaweq_> yep
14:24:07 <ajo> as far as I understood, we can't proceed until we have something like api microversioning
14:24:10 <slaweq_> and I wanted to ask about what to do with it?
14:24:16 <slaweq_> exactly
14:24:20 <ajo> slaweq_, probably document and wait
14:24:24 <slaweq_> as You and ihrachys said in review
14:24:34 <slaweq_> document on launchpad? or where?
14:24:55 <ajo> slaweq_, the api guide, probably, and the adv networking guide
14:25:00 <slaweq_> ah, ok
14:25:12 <slaweq_> no problem, I have some experience with that already :)
14:25:17 <ajo> slaweq_++
14:25:21 <ajo> awesome, thanks :)
14:25:26 <njohnston> +1
14:25:46 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1515564
14:25:47 <openstack> Launchpad bug 1515564 in neutron "Internal server error when running qos-bandwidth-limit-rule-update as a tenant" [Low,In progress] - Assigned to Liyingjun (liyingjun)
14:26:38 <ajo> #link https://review.openstack.org/#/c/244680/  needs reviews
14:27:01 <ajo> I totally missed it, adding it to my queue
14:27:59 <ajo> I suspect that patch will conflict with the qos_plugin refactor mfrances was working on
14:28:20 <ajo> mfranc213, if you can ask the author to follow up on your patch, that would be the best I think
14:28:52 <ajo> which is: https://review.openstack.org/#/c/294463/
14:29:40 <ajo> next is
14:29:41 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1558614
14:29:42 <openstack> Launchpad bug 1558614 in neutron "The QoS notification_driver is just a service_provider, and we should look into moving to that" [Low,In progress] - Assigned to Ching Sun (ching-sun)
14:30:20 <mfranc213> ajo: i'll get in touch with the author.  thanks for this.
14:30:20 <ajo> I see we have a question to answer, I still don't have the exact answer
14:30:28 <ajo> it's not a simple change of config name,
14:30:52 <ajo> we may need to look into the service_providers thing, see how it works, and if it fits what we do with the notifications_driver
14:30:56 <ajo> but it seems very similar.
14:31:08 <ajo> May be it does not 100% fit
14:31:24 <ajo> because with service providers, you can specify different providers for the same service
14:31:29 <ajo> and that won't work in our case,
14:31:56 <ajo> I will link that bug to this log, and discuss in there as soon as we have a clear answer
14:32:12 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1507656
14:32:13 <openstack> Launchpad bug 1507656 in neutron "RPC callbacks push/pull mechanism should be remotable" [Wishlist,Confirmed] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
14:32:56 <njohnston> I wasn't sure if that was large enough to warrant an RFE
14:33:05 <ajo> that one doesn't really add any new feature
14:33:11 <ajo> is more like a refactor of the rpc callbacks code
14:33:15 <njohnston> Ok
14:33:40 <ajo> I think push can't use what ihrachys proposes, but I'm sure pull could
14:34:05 <ajo> we may eventually look at it when we have time. or move to Won't fix if that doesn't happen.
14:34:23 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1556836
14:34:24 <openstack> Launchpad bug 1556836 in neutron "QOS: TestQosPlugin should receive plugin name as an input" [Wishlist,In progress] - Assigned to Adit Sarfaty (asarfaty)
14:34:59 <ajo> ah
14:35:03 <ajo> that doesn't apply anymore
14:35:15 <ajo> because they did it the right way and stopped subclassing the QoS plugin
14:35:53 <ajo> bugs--
14:35:56 <ajo> that feels good :)
14:36:07 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1560963
14:36:08 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,Confirmed]
14:36:11 <ajo> irenab, you were asking about this one
14:36:26 <irenab> ajo: I was patiently waiting
14:36:33 <ajo> you were very patient :)
14:36:38 <ajo> There's an ongoing design in the nova scheduler about this
14:36:59 <ajo> The idea is that they made some generic entities that we can fill in, to let the scheduler account resources
14:37:00 <ajo> in our case
14:37:14 <ajo> we could create pools (of traffic) attached to the hosts,
14:37:27 <ajo> (1 compute) --- (1 bandwidth pool)
14:37:54 <ajo> and then, when nova had to schedule an instance with a port that requires "NIC_BW" of 1Gbit
14:38:07 <ajo> it would look for the right pool (and therefore the right compute) to host it
14:38:25 <ajo> and it would also count down the used traffic from the bandwidth pool attached to such compute
14:38:38 <ajo> on that discussion
14:38:57 <ajo> we noticed that, for that to happen, nova may need to look at the qos_policy_id and make an interpretation of a policy
14:39:07 <ajo> looking for guaranteed traffic rules in the policy
14:39:26 <ajo> which is too coupled, since nova would have to understand the policies, the rules, which are supposed to be evolving
14:39:27 <ajo> so..
14:39:57 <ajo> there was  suggestion from jaypipes to add an API to translate port uuids (or other objects), to scheduler constraints/scheduler resource usages
14:40:22 <ajo> that's a good idea IMHO,
14:40:37 <irenab> nova API?
14:40:43 <ajo> no, neutron api
14:41:06 <ajo> you would give that API a port id, and you would get a set of constraints/or resource usages for the scheduler
14:41:23 <irenab> nica
14:41:25 <irenab> nise
14:41:29 <ajo> ./get-scheduling-details/port/<port-uuid> ->
14:41:29 <irenab> nice :-)
14:41:41 <ajo> {"NIC_BW": 10000000,  blah, blah: ..}
14:42:00 <ajo> the only issue we found about that, is that it would add another call from nova to neutron
14:42:01 * njohnston has to go now... I will catch up with the transcript later. Thanks ajo!
14:42:06 <jaypipes> irenab: an API that Nova (or the broken out scheduler) can call to Neutron to get information about the networking-related resource providers (like IPv4 address, etc)
14:42:07 <ajo> thanks njohnston !
14:42:24 <ajo> hi jaypipes :)
14:42:29 <slaweq_> ajo: can't it be given in port-show call?
14:42:36 <ajo> irenab, jaypipes ,
14:42:37 <slaweq_> like now is policy-id
14:42:43 <ajo> exactly, what slaweq_ is saying is what I was about to say
14:42:46 <ajo> we could do better
14:42:54 <slaweq_> sorry :)
14:42:57 <ajo> if we provide in the resource creation or show...
14:42:59 <ajo> that dictionary
14:43:06 <ajo> as a read only attribute of the port
14:43:14 <irenab> there is actually already port binding extension that has 2 dicts
14:43:15 <ajo> that would avoid the extra API call from nova to neutron
14:43:50 <ajo> irenab, aha, that's interesting, what are those dicts?
14:43:53 <irenab> so maybe the vif_details or profile can be used
14:44:02 <ajo> irenab, that's ml2 specific
14:44:11 <ajo> we should come up with something wide for all plugins,
14:44:24 <irenab> no, this is about supporting port binding extension
14:44:25 <ajo> and may be move those details from ml2 back into the generalized one
14:45:01 <ajo> irenab, ok, but what I mean, is that if we put those scheduling details in the port binding extension dictionary, that's ml2 specific
14:45:10 <ajo> and won't be available to other non-ml2 plugins
14:45:26 <irenab> so you prefer separate extension? Fair enough
14:45:46 <ajo> yes, and I guess we will depend in the "core extension manager" that ihrachys and I were thinking of
14:45:49 <ajo> so two RFEs:
14:45:52 <ajo> * core extension manager
14:46:00 <irenab> but I think the port binding is supported by others and actually maybe required by new vif lib
14:46:01 <ajo> * scheduling details for nova
14:46:34 <ajo> irenab, if it becomes required by vif_lib it will be an error we can't stop supporting non-ml2 plugins
14:46:48 <ajo> as an example: OVN on the open side of things
14:46:52 <irenab> why do you think its ml2 specifc?
14:47:13 <ajo> irenab, may be it's not ml2 specific, and I'm mistaken :)
14:47:13 <irenab> https://github.com/openstack/neutron/blob/master/neutron/extensions/portbindings.py
14:47:42 <slaweq_> ajo: I agree with irenab, every plugin can support such extension
14:47:48 <irenab> but its implementation details anyway :-)
14:47:59 <ajo> yeah, may be it makes sense
14:48:09 <ajo> let's look at it, thanks irenab  :)
14:49:07 <ajo> we would have to come up with something to look up for the qos_policy details of a port and synthetize the thing into another dict there
14:49:13 <ajo> or another detail in the dict
14:49:36 * ajo is a little bit stubborn sometimes ;)
14:49:49 <ajo> ah
14:49:51 <ajo> and about this RFE
14:49:56 <ajo> I should probably split it in two
14:50:02 <ajo> 1) best effort
14:50:07 <ajo> 2) strict (with nova scheduling)
14:50:20 <ajo> 1 would take care of the low level settings on each compute host to make it happen
14:50:27 <ajo> (sriov settings, ovs settings, etc..)
14:50:50 <irenab> another question about guarantee, is it for edge only or should consider the end to end fabric?
14:50:50 <ajo> I'm afraid we have 10 minutes and lots of RFEs to look at yet
14:51:18 <ajo> irenab, initially only for edge, we could think of wider thing later
14:51:29 <irenab> fine
14:51:40 <ajo> irenab, but that would require modelling the whole underlaying network,
14:51:54 <ajo> and not sure if we can keep control over all the traffic flows :)
14:52:04 <ajo> sounds like an interesting and very hard problem
14:52:20 <irenab> I would say, it would require neutron to be responsible
14:52:44 <irenab> or maybe new project will come  to deal with it :-)
14:52:51 <ajo> lol :)
14:53:46 <ajo> I will skip some RFEs, (lack of time)
14:53:47 <ajo> #
14:53:47 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1527671
14:53:48 <openstack> Launchpad bug 1527671 in neutron "[RFE] traffic classification in Neutron QoS" [Wishlist,Incomplete]
14:54:04 <ajo> davidsha, we talked about this one ^, and there's where Cathy's meeting comes,
14:54:08 <ajo> luckily on Tuesday lunch
14:55:20 <davidsha> I'll be there
14:55:34 <ajo> about https://bugs.launchpad.net/neutron/+bug/1557457 , jun wei updated his description, I need to re-read it
14:55:35 <openstack> Launchpad bug 1557457 in neutron "[RFE] bandwidth rate-limit" [Wishlist,Incomplete]
14:55:40 <ajo> #action ajo have another look at https://bugs.launchpad.net/neutron/+bug/1557457
14:56:18 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1531485
14:56:19 <openstack> Launchpad bug 1531485 in neutron "Available device bandwidth report by L2 agent" [Wishlist,Expired]
14:56:53 <ajo> this one is expired, but it may happen in the context of https://bugs.launchpad.net/neutron/+bug/1560963   (when reporting to the nova generic resource pools)
14:56:54 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,Confirmed]
14:57:22 <ajo> and
14:57:30 <ajo> finally slaweq_ is also working on these doc changes: https://review.openstack.org/#/c/307193
14:57:46 <ajo> explaining about burst values, and how should those be configured
14:57:52 <ajo> #topic Open discussion
14:58:07 <ajo> anything to talk about in our remaining 2 minutes? :)
14:58:19 <slaweq_> I'm also working on https://bugs.launchpad.net/neutron/+bug/1560961
14:58:20 <openstack> Launchpad bug 1560961 in neutron "[RFE] Allow instance-ingress bandwidth limiting" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:58:24 <slaweq_> but it's just begining now
14:58:56 <ajo> oh, right, slaweq_ thanks about that too, you're doing an amazing job
14:59:05 <slaweq_> thx :)
14:59:25 <ajo> ok so
14:59:28 <ajo> let's endmeeting
14:59:30 <ajo> o/
14:59:41 <ajo> thanks everybody
14:59:41 <davidsha> thanks
14:59:45 <slaweq_> thanks
14:59:47 <irenab> thanks
14:59:50 <slaweq_> see You in Austin :)
14:59:56 <ajo> see you :)
14:59:58 <ajo> #endmeeting