14:03:57 <njohnston> #startmeeting neutron_qos
14:03:57 <openstack> Meeting started Wed Sep 21 14:03:57 2016 UTC and is due to finish in 60 minutes.  The chair is njohnston. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:57 <njohnston> #chair ajo
14:03:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:04:00 <openstack> The meeting name has been set to 'neutron_qos'
14:04:01 <openstack> Current chairs: ajo njohnston
14:04:06 <njohnston> Since we are all probably spending a lot of time testing Newton, I'd just like to focus on things that have velocity at the moment, and probably keep this meeting short.
14:04:07 <ajo> you were not late ralonsoh , see? :D
14:04:21 <ralonsoh> ajo: Thanks!
14:04:26 <ajo> thanks njohnston ! :
14:04:28 <ajo> :)
14:04:32 <njohnston> sorry about that
14:05:10 <ajo> sorry njohnston go ahead with the plan, leave me a slot for the nova-placement-api details & ihar comments about prioritizing validation :)
14:05:10 <njohnston> #topic RFEs
14:05:10 <njohnston> #link https://review.openstack.org/#/c/318531/
14:05:38 <njohnston> #link https://review.openstack.org/#/c/318531/
14:05:38 <njohnston> [WIP] Add QoS minimum egress bandwidth rule into ovs-agent:
14:05:38 <njohnston> - Use ralonsoh implementation: use QoS on all br-int ports and external ports.
14:05:40 <njohnston> - Use Ichihara implementation: reduced scope, only apply QoS on external ports.
14:05:42 <ralonsoh> I'm in the middle of a discussion with Hirofumi
14:05:57 <ralonsoh> I you can review that, that could be helpful
14:06:20 <ajo> do we have two implementations ?
14:06:26 <ralonsoh> Yes
14:06:30 <ajo> oh ':D
14:06:40 <ralonsoh> patch 10: my imp,ementation
14:06:48 <ralonsoh> with full qos applied to all ports
14:06:58 <ralonsoh> patch 13: qos only applied to external ports
14:07:25 <ralonsoh> It's a matter of define the scope
14:07:54 <ralonsoh> No more comments
14:07:57 <ajo> Would anything block us by starting on external
14:08:04 <ajo> and then adding internal too if we find it reasonable?
14:08:12 <ralonsoh> Perfect!
14:08:34 <ajo> I mean, if we hear of a use case for internal too that requires it, then we add it
14:08:35 <ralonsoh> I'll talk to Hirofumi to take care of this patch
14:08:45 <ajo> and otherwise, we assume internal traffic is not constrained
14:08:58 <ralonsoh> ajo: I agree with this scope
14:09:01 <ajo> as generally doesn't have the limitation of the external uplink, but CPU is limited
14:09:06 <ajo> ralonsoh++
14:10:10 <njohnston> #topic Bugs
14:10:10 <njohnston> #link https://review.openstack.org/#/c/367369/
14:10:10 <njohnston> Fix SR-IOV qos extension calls to clear_rate functions:
14:10:41 <ralonsoh> Yes. That's a small bug
14:10:50 <ralonsoh> I'm asking for reviews
14:10:57 <ralonsoh> only this
14:11:17 <ajo> ralonsoh, is it a bug, or enhancement to design?
14:11:32 <ajo> I mean (to consider if we need to push it to the next RC)
14:11:52 <ralonsoh> enhancement
14:12:14 <ajo> ack :)
14:12:14 <ralonsoh> But we need to change the name of the function calls
14:12:18 <ralonsoh> Thanks
14:12:29 <njohnston> if this waits until Ocata, will we need to drop a deprecation warning for the old function call names?
14:13:13 <ralonsoh> We will need to check ip-link has these features
14:13:20 <ralonsoh> No need for deprecation
14:13:27 <ralonsoh> But I'll review that
14:13:41 <njohnston> very good
14:13:46 <njohnston> #link https://bugs.launchpad.net/bgpvpn/+bug/1622644
14:13:47 <openstack> Launchpad bug 1622644 in networking-bgpvpn "OVS agent ryu/native implementation breaks non-OF1.3 uses" [Critical,Confirmed]
14:13:47 <njohnston> The change related to this is: "fullstack: execute qos tests for all ovsdb/of interface permutations"
14:13:47 <njohnston> #link https://review.openstack.org/372553
14:13:47 <ajo> it's internal API
14:13:53 <ajo> so I guess no need for deprecation
14:14:08 <njohnston> I thought people should be aware of this, because it's good stuff
14:14:31 <ajo> yeah :D
14:14:53 <ajo> tiny change, full test coverage
14:14:56 <ajo> ihar++ :)
14:15:27 <njohnston> #topic Other Changes
14:15:33 <njohnston> ralonsoh: How goes the OSC patches?
14:15:47 <njohnston> I saw a new PS on at least one recently
14:15:51 <ralonsoh> waiting for qos policy
14:15:56 <ralonsoh> the first one
14:16:10 <ralonsoh> only one +2
14:16:24 <ralonsoh> and a comment: "waiting for dtroyer comments"
14:16:43 <ajo> ralonsoh, do we have support to attach policy to port or network ?
14:16:46 <njohnston> perhaps it would help to ping in #openstack-sdks
14:17:05 <ajo> +ping :)
14:17:09 <ralonsoh> ajo: what do you mean
14:17:14 <ralonsoh> ?
14:17:19 <ajo> like the neutron port-update --qos-policy my-policy
14:17:26 <ajo> or neutron port-update --no-policy
14:17:29 <ajo> same for net
14:17:39 <ralonsoh> ajo: hmmmm I need to check this
14:17:48 <ralonsoh> ok, new bug for OSC
14:17:49 <ajo> neutron client provides that capability, but not sure if we already had patches for that, ok
14:17:53 <ajo> X')
14:18:03 <ajo> I just realized we were missing that tiny bit :D
14:18:05 <ralonsoh> I'll take care of this
14:18:18 <ajo> you're awesome ralonsoh
14:18:28 <ralonsoh> thanks
14:18:36 <njohnston> ralonsoh += awesome
14:18:54 <njohnston> ajo: "leave me a slot for the nova-placement-api details & ihar comments about prioritizing validation".  You have the floor!
14:19:01 <ajo> oooook :)
14:19:18 <ajo> #topic minimum bandwidth egress (strict) RFE
14:19:32 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1578989
14:19:33 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,Confirmed]
14:19:55 <ajo> this is something we expect to span from Ocata to beyond, requires no more API changes,
14:20:11 <ajo> unless we want to flag the min bw rules for strict or not
14:20:20 <ajo> that's something we could perhaps discuss
14:20:23 <ajo> but
14:20:30 <ajo> this is the feature that requires integration with "nova scheduler"
14:20:46 <ajo> I got a great update today from sylvainb (Sylvain Bauzas)
14:20:49 <ajo> from the nova team
14:20:57 <ralonsoh> I've been working with nova scheduler
14:21:08 <ajo> The generic resource pools spec materialized as a new API endpoint
14:21:12 <ajo> the nova placement API
14:21:13 <ralonsoh> I know how to do this and I made a POC in my company a year ago
14:21:35 <ajo> ralonsoh, we can't hook up a plugin on the scheduler for this, but we have a plan
14:21:36 <ajo> :)
14:21:42 <ajo> so
14:21:48 <ajo> nova came up with this spec:
14:21:50 <ajo> #link http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html
14:21:58 <ajo> it's implemented for newton, the API is available
14:22:06 <ralonsoh> perfect
14:22:22 <ajo> it will let you to declare (via API) resource pools ( DISK_GB, RAM, etc...) and eventually
14:22:22 <njohnston> ajo: very nice!
14:22:30 <ajo> NIC_BW_<physnet>_<direction>
14:22:48 <ajo> and then we would expose those requirements on the neutron ports when got by nova
14:23:02 <ajo> so before scheduling the instance, nova would have to create (or get) the port, check the requirements
14:23:14 <ajo> and find a hypervisor satisfying the needed bandwidth
14:23:39 <ajo> this is the devstack support to enable such API:
14:23:41 <ajo> #link devstack support: https://review.openstack.org/#/c/342362/
14:24:08 <ajo> so far, the API is not ready to declare custom resource classes
14:24:22 <ajo> (that means different types of NIC_BW (per physnet and direction))
14:24:39 <ajo> wip spec on nova for custom resource classes:
14:24:42 <ajo> #link https://review.openstack.org/#/c/312696/
14:24:50 <ajo> and
14:24:58 <ajo> example of resource reporting from nova to such API:
14:25:00 <ajo> #link  https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py
14:25:03 <ajo> they do it via http
14:25:14 <ajo> so
14:25:17 <ajo> we would need to
14:25:29 <ajo> 1) Collect available bandwidth on each agent, per physnet
14:25:46 <ajo> 2) Report it via this API, or to a central service in neutron, that will in turn report to the nova api
14:25:57 <ajo> that's the total amount of bw
14:26:16 <ajo> 3) we would need the custom resource classes to be there
14:26:38 <ajo> or we could tweak it in the mean time by having a "non-merged" patch in nova to have a generic NIC_BW or a bunch of them, just for testing
14:26:41 <ajo> until they merge it
14:26:48 <ajo> Depends-On, etc...
14:26:52 <njohnston> yep
14:27:01 <ajo> 4) exposing those constraints on a port-get from nova
14:27:25 <ajo> 5) making nova create/get the port before trying to schedule the port (apparently they will implement that on Ocata for Cells v2)
14:27:51 <ajo> 6) and make sure they use/count those details
14:27:57 <ajo> probably that's it :)
14:28:14 <ajo> ah
14:28:17 <ajo> one point
14:28:22 <ralonsoh> good analysis!
14:28:25 <ajo> if you see their scheduler/client/report.py
14:28:33 <ajo> you will see that there is no integration of such api in the nova client
14:28:38 <ajo> there's no client still for the nova placement api
14:29:05 <ajo> A possible plan could be using their code (copying to neutron), and once there's a common client, making use of it
14:29:16 <ajo> a common client, likely to be "support in the openstack sdk" :-9
14:29:18 <ajo> :-)
14:29:36 <ajo> So, this is a effort to probably span Ocata -> beyond
14:30:04 <njohnston> this is some awesome news
14:30:13 <ajo> but we should consider start making progress on it and not waiting for the whole thing (custom resource types in nova) when we see it fit
14:30:36 <ajo> I will start myself by exploring the nova API, and writting a more detailed plan
14:30:55 <ajo> may be a full spec? since this seems to be a complicated chunk
14:31:17 <ajo> #action ajo starts writing a spec
14:31:20 <njohnston> Yes, I think this is probably good for a spec
14:31:21 <ajo> #undo
14:31:22 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x7f23bda80150>
14:31:41 <ajo> #action ajo starts writing a spec for strict bandwidth guarantees and nova placement api integration
14:31:55 <ajo> any comments about this topic?
14:32:17 <ralonsoh> I'm very interested in help with that
14:32:50 <njohnston> super cool
14:32:50 <ajo> ralonsoh, great, let's talk during the summit (probably, with more details on hand), I'll loop you in the spec
14:33:04 <ajo> so, last topic then?
14:33:15 <njohnston> yep
14:33:16 <njohnston> #topic Open Discussion
14:33:21 <njohnston> anything else?
14:33:24 <ajo> so, we have
14:33:31 <liuyulong__> hi guys
14:33:34 <ajo> the enhanced rule validation that slaweq was working on
14:33:54 <ajo> this has to go before any new kind of new policy rule we introduce
14:34:01 <ajo> to avoid things getting out of hand :)
14:34:21 <ajo> and, also I need to refactor the notification driver thing into a "qos driver" thing, to be more consistent
14:34:26 <njohnston> yep; I don't recall seeing anything new on that recently, but I think it is an early-Ocata must-have
14:34:47 <ajo> so I should resume my chunk of work ':)
14:34:49 <liuyulong__> sorry to interrupt, : (
14:34:51 <ajo> that's all on my side
14:34:58 <njohnston> liuyulong__: go ahead
14:34:59 <ajo> liuyulong_,  go ahead, sorry :)
14:35:05 <liuyulong__> I have a draft RFE spec, https://github.com/gotostack/gotostack.github.io/blob/master/pages/CloudComputing/layer-3-rate-limit.rst. It’s something about L3 qos. Hope to get some help, if you guys have time. I'm always in the openstack-neutron channel. Thank you. : )
14:35:27 <liuyulong__> #link https://bugs.launchpad.net/neutron/+bug/1596611
14:35:30 <openstack> Launchpad bug 1596611 in neutron "[RFE] Create floating-ips with qos" [Wishlist,Triaged] - Assigned to LiuYong (liu-yong8)
14:36:20 <ajo> liuyulong__,  question
14:36:29 <ajo> isn't that equivalent to limiting the external leg of the router ?
14:36:37 <ajo> I only readed it diagonally, so probably not
14:36:57 <ajo> ah, per floating ip?
14:36:59 <liuyulong__> ajo, yep, east/west will not
14:37:18 <liuyulong__> ajo, only for public IPs (v4)
14:37:37 <ajo> yes, but east/west doesn't go through the external leg of the router
14:38:03 <ajo> in the current implementation you could acomplish that (for egress only) if you put a bandwidth limit policy on the external leg of the router
14:38:08 <liuyulong__> ajo, yes, east/west will be handled by current QoS implementation.
14:38:09 <ajo> but not by IP, only globally
14:38:46 <ajo> I think it's better if we don't spread the qos details across objects/and stuff (like floating ips)
14:38:52 <ajo> several alternatives could be
14:39:05 <ajo> 1) Attaching policies to floating IPs ?
14:39:29 <ajo> 2) Having traffic classification (you can filter on the IP for the limit) and attach policy to external router leg
14:39:35 <njohnston> and I'm not sure how this would vary based on whether there is fast-exit routing versus return path routing through the network node
14:40:08 <liuyulong__> ajo, actually we've already implement this by using linux tc in router namespace.
14:40:26 <ajo> liuyulong__, yes, It's completely possible
14:40:46 <liuyulong__> ajo, locally in our mitaka neutron, : )
14:40:48 <ajo> liuyulong___ but the complicated part is not implementing an API and the code (it has it's merit of course)
14:41:00 <ajo> the complicated part is agreeing an API with the community
14:41:13 <ajo> then what, when somebody wants to apply DSCP rules per floating IP ?
14:41:18 <ajo> or min bw rules per floating IP ?
14:41:21 <liuyulong__> ajo, yep, so I'm here to find some help/advice and so on.
14:41:36 <ajo> may be the model is to let floating IPs being associated to QoS policies
14:41:39 <ajo> but that'd mean
14:41:49 <ajo> that we have some basic mean of doing traffic classification
14:41:55 <ajo> because from an ovs agent point of view
14:42:15 <ajo> we'd have to apply it on port level
14:42:17 <liuyulong__> ajo, people may want to know how large the bandwidth of their floating IP.
14:42:21 <ajo> it's worth thinking about it
14:42:27 <ajo> seems like a reasonable use case
14:42:57 <ajo> liuyulong__, they could see the policy_id on the floating ip
14:43:00 <ajo> and then check the policy
14:43:29 <liuyulong__> ajo, and cloud admins also want limit the users' floating IP bandwidth, because of the limitation of the NIC or DC export.
14:43:48 <ajo> yes yes, liuyulong__ I'm not discussing the use case
14:43:52 <ajo> I believe it's valuable
14:44:01 <njohnston> should we continue this discussion on the bug?
14:44:20 <ajo> we should continue discussion,
14:44:34 <ajo> on the bug, I mean
14:44:43 <liuyulong__> ajo, So, should I submit the draft spec to review? We can talk about it there?
14:45:00 <ajo> liuyulong__ yeah, may be a draft spec makes sense, but please don't open blueprints,
14:45:08 <ajo> that's done by the driver team once an RFE has been approved
14:45:26 <ajo> liuyulong__ you may also want to discuss with slaweq
14:45:31 <liuyulong__> ajo, OK, I have not.
14:45:35 <ajo> he works at OVH, has been working on the current APIs,
14:45:44 <ajo> and he's probably interested in your use case too
14:46:08 <liuyulong__> ajo, great, thanks.
14:46:44 <njohnston> super
14:46:52 <njohnston> does anyone have anything else?
14:47:41 <njohnston> ok, hearing nothing else I'll give 12 minutes back.  Thanks!
14:47:50 <ajo> njohnston++ thank you very much
14:47:55 <njohnston> #endmeeting