14:00:02 <njohnston> #startmeeting neutron_qos 14:00:03 <openstack> Meeting started Wed Jun 29 14:00:02 2016 UTC and is due to finish in 60 minutes. The chair is njohnston. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:07 <openstack> The meeting name has been set to 'neutron_qos' 14:00:09 <njohnston> #chair ajo 14:00:14 <openstack> Current chairs: ajo njohnston 14:00:31 <njohnston> good morning all 14:00:46 <njohnston> #topic announcements 14:01:00 <njohnston> We are in week R-14; N-2 is at R-12 http://releases.openstack.org/newton/schedule.html 14:01:37 <njohnston> Also, keep an eye on QoS commands for the OSC transition: https://etherpad.openstack.org/p/osc-neutron-support - AFAIK we haven't done anything on this yet. 14:01:46 <ajo_> we're in the middle of the cycle. 14:02:30 <njohnston> Yep! And I think we have had good velocity for change of late. Just making sure we don't forget. 14:02:55 <njohnston> Anyone have anything else for announcements? 14:03:43 <njohnston> #topic Approved RFEs 14:03:43 <njohnston> #link http://tinyurl.com/qos-rfe-approved 14:04:03 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1560961 14:04:03 <openstack> Launchpad bug 1560961 in neutron "[RFE] Allow instance-ingress bandwidth limiting" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq) 14:04:17 <njohnston> Last I heard, slaweq has stopped working on this pending https://bugs.launchpad.net/neutron/+bug/1586056 (extended validation) 14:04:17 <openstack> Launchpad bug 1586056 in neutron "[RFE] Improved validation mechanism for QoS rules with port types" [Wishlist,Confirmed] - Assigned to Slawek Kaplonski (slaweq) 14:04:22 <njohnston> Change is: https://review.openstack.org/#/c/303626/ 14:04:49 <njohnston> and the other approved RFE is 14:04:51 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1560963 14:04:51 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) 14:04:51 <ajo_> correct 14:04:52 <ajo_> we need to settle into something and do the job, to unblock the other things 14:05:33 <njohnston> indeed 14:05:57 <njohnston> I don't think there si much tot alk about here 14:06:06 <njohnston> I don't think there is much to talk about here 14:06:25 <njohnston> #topic Not Yet Approved RFEs 14:06:25 <njohnston> #link http://tinyurl.com/qos-rfe-unapproved 14:06:35 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1505627 14:06:35 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Incomplete] - Assigned to Reedip (reedip-banerjee) 14:06:42 <njohnston> This is reedip's ECN RFE 14:07:15 <njohnston> I do not see reedip online 14:07:40 <njohnston> But for the record, what I'd like to see on this: use cases, and some sketch of details on a reference implementation. 14:07:51 <njohnston> ECN is autonegotiated if both sides indicate they can support it. If our implementation is going to go beyond just enabling/disabling support, we need to see how it will work without Neutron having to inspect packets at line rate. 14:08:09 <njohnston> I will link in the bug to the meeting log. 14:08:35 <njohnston> ajo_: Does that pretty well cover this? 14:09:23 <davidsha> Think he's DC 14:09:31 <njohnston> ok 14:09:35 <njohnston> hello davidsha! 14:09:40 <davidsha> hey :D 14:09:45 <njohnston> moving on to 14:09:47 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1586056 14:09:47 <openstack> Launchpad bug 1586056 in neutron "[RFE] Improved validation mechanism for QoS rules with port types" [Wishlist,Confirmed] - Assigned to Slawek Kaplonski (slaweq) 14:09:57 <njohnston> This is the big blocker 14:10:05 <njohnston> Looks like we are waiting on ihrachys to respond to Ajo's question on the bug. 14:10:14 <ajo_> which one sorry, 14:10:23 <ajo_> to make things funnier, I'm having connection issues 14:10:26 <davidsha> https://bugs.launchpad.net/neutron/+bug/1586056 14:10:28 <ajo_> thanks 14:10:30 <njohnston> Oh that's just unfair 14:10:32 <davidsha> np 14:10:42 <ihrachys> does it require my involvement? hm. 14:11:00 <ihrachys> I think the last comment from @ajo addresses the goal neatly 14:11:01 <ajo_> njohnston, there was no question, we're talking on the spec 14:11:13 <njohnston> ajo_: OK, I mis-read it then. So we are in accord? 14:11:14 <ajo_> https://review.openstack.org/#/c/323474/6 14:11:28 <ajo_> the remaining question was if we were proposing to introduce a field to a rule in the spec, which is not the case 14:11:34 <ajo_> so I will clarify that, 14:12:06 <ajo_> but still, we must do parameter validation (not just rule type validation) to have something complete and (hopefully) no need to worry about that again (how optimistic I am..) 14:12:08 <ihrachys> right. so just remove the notion of --direction, and it should be good 14:12:20 <ajo_> I will make the example agnostic 14:12:35 <ihrachys> and then when we need --direction, we build on top of the validation framework you introduce with the spec 14:12:52 <ihrachys> does it capture the idea properly? 14:13:09 <davidsha> ihrachys: he just disconnected I think 14:13:18 * ajo_ curses his connection 14:13:23 <ihrachys> ajo_: "and then when we need --direction, we build on top of the validation framework you introduce with the spec" 14:13:27 <ihrachys> is it correct? 14:13:51 <ajo_> I would do all the validation now, and then we we have --direction, we add the direction possibilities per mechanism driver 14:14:20 <ihrachys> right. I think I expressed the same thing. we are on the same page. 14:14:34 <ihrachys> does the spec include expanding the list of supported rule types to superset? 14:14:40 <ihrachys> I assume no, but better check 14:14:53 <ihrachys> because the original patch from slaweq included that too, I think 14:15:02 <ajo_> you're right on both things 14:15:08 <ajo_> we should not change the semantics of the API reporting 14:15:39 <ajo_> eventually we can make a different reporting later, or through microversioning in the future 14:16:06 <ajo_> but without microversioning it should be a different url, anyway, that's out of the spec, and we could bring it up if necessary in the future 14:16:45 <ajo_> reporting is out, basically because there were a few inconsistiencies in the possibilities of vnic / binding_type, etc... 14:17:02 <ajo_> so 14:17:15 <ajo_> #action ajo bump the extended validation spec to address Ihar comments & concerns 14:17:34 * ajo_ wonders if he's still online, and pings himself :D 14:17:42 <ihrachys> I will check the spec right now to make sure you have everything to address in one go 14:17:42 <davidsha> your good :) 14:18:43 <njohnston> Great, thanks ihrachys and ajo_. That definitely made things clearer for me. 14:19:07 <njohnston> #topic Bugs 14:19:07 <njohnston> #link http://bit.ly/1WhXlzm\ 14:19:18 <njohnston> #link https://bugs.launchpad.net/networking-ovn/+bug/1584204 14:19:18 <openstack> Launchpad bug 1584204 in neutron "VersionsCallbackNotFound exception when using QoS" [Undecided,In progress] - Assigned to John Kasperski (jckasper) 14:19:23 <njohnston> I think this is done now for master, working on mitaka backport 14:20:02 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1589969 14:20:02 <openstack> Launchpad bug 1589969 in neutron "[qos][postgresql] neutron qos-bandwidth-limit-rule-create failed" [Medium,Confirmed] - Assigned to Miguel Angel Ajo (mangelajo) 14:20:47 <njohnston> No action on this yet. ajo_ linked to a bug that has since been resolved, it looks like, but in a way where I'm not sure how that affects pgsql setups. 14:21:48 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1515564 14:21:48 <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:21:49 <ihrachys> I think I posted there what's the clue 14:21:56 <ihrachys> for the prev bug you mentioned... 14:22:05 <njohnston> The pgsql one? 14:22:07 <ihrachys> yes 14:22:27 <davidsha> this PS right? https://review.openstack.org/#/c/300055/ 14:22:32 <njohnston> ah, I see 14:23:06 <ihrachys> we don't use common_db_mixin mechanisms for get_objects/get_object till M/N 14:23:10 <ihrachys> and we should 14:23:29 <ihrachys> that should hide the issue for psql 14:23:46 <ihrachys> davidsha: yes, pieces of it 14:24:07 <ajo_> I was saying: I'm having some busy time until past mid july, and then I can jump into it, but if anyone else has cycles to look at it, I can release the bug 14:24:54 <ihrachys> I think it's now a matter of backports 14:25:24 <ihrachys> I would mark as fixed, add tags for backports, and go on with your life 14:25:50 <ajo_> ihrachys, we need to verify it really went away 14:25:52 <ajo_> at least :) 14:25:59 <slaweq> hello, sorry for late 14:26:05 <ihrachys> ajo_: as you wish :) 14:26:16 <njohnston> Hi slaweq! 14:26:57 <njohnston> #action Make sure https://bugs.launchpad.net/neutron/+bug/1589969 is fixed, then add tags for backports 14:26:57 <openstack> Launchpad bug 1589969 in neutron "[qos][postgresql] neutron qos-bandwidth-limit-rule-create failed" [Medium,Confirmed] 14:27:20 <ihrachys> njohnston: whose action is it? 14:27:48 <njohnston> I don't have a pgsql setup, but I can take a whack at it 14:28:17 <slaweq> I have devstack with pgsql running 14:28:20 <ihrachys> should probably be easy with devstack 14:28:23 <slaweq> so I can check it if You want 14:28:44 <njohnston> slaweq: I will take you up on that then 14:28:48 <njohnston> #undo 14:28:48 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x7f2b36a23d10> 14:29:08 <njohnston> #action slaweq to make sure https://bugs.launchpad.net/neutron/+bug/1589969 is fixed, then add tags for backports 14:29:09 <openstack> Launchpad bug 1589969 in neutron "[qos][postgresql] neutron qos-bandwidth-limit-rule-create failed" [Medium,Confirmed] 14:29:17 <slaweq> ok 14:29:27 <njohnston> Thanks slaweq 14:30:08 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1515564 14:30:08 <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:30:36 <njohnston> This one is still active, looks like there is some feedback to address 14:30:40 <ajo_> slaweq++ 14:30:44 <njohnston> but I think it's getting close 14:31:22 <ihrachys> there is a lot of things to address there 14:31:32 <ihrachys> because we went the new version of the objects path 14:32:20 <ihrachys> note that the fix as proposed now won't be backportable 14:32:50 <njohnston> Does this one need a reno note? 14:33:21 <ihrachys> I don't think so. 14:33:24 <njohnston> ok 14:33:30 <ihrachys> it fixes a bug, nothing fancy 14:33:35 <ihrachys> even though the fix is involving 14:34:38 <njohnston> #topic Open Discussion 14:35:19 <njohnston> A QoS question came up in the mailing list. I haven't had the bandwidth to really think about it, but I wanted to see if anyone wanted to respond. 14:35:24 <njohnston> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/098207.html 14:36:20 <ihrachys> hm, qg maintains all FIPs at the same time right? 14:36:20 <ajo_> yes, to implement that we need to do it on the routers 14:36:37 <ihrachys> so you can't just TC on the gq port 14:37:03 <ajo_> or, in the DVR implementation details... 14:37:14 <ajo_> but yes, doing it on the vm ports won't help 14:37:48 <ihrachys> well we could apply FIP port policies on relevant VM ports, but that is twisted behaviour for my taste 14:37:55 <ihrachys> because it will still limit internal traffic 14:38:40 <ihrachys> a router would probably need to apply some advanced traffic classification to slow down traffic destined for specific fixed ips 14:40:50 <njohnston> OK, good, I thought that the answer was not totally straightforward. 14:41:32 <njohnston> Should we encourage the author to file this as a bug so we can discuss it in more detail in launchpad? 14:42:49 * njohnston fears we lost ajo_ for good. 14:43:03 <ihrachys> njohnston: I think we should suggest RFE 14:43:04 <ajo> njohnston, may be an RFE makes sense here 14:43:10 <ajo> to keep us all thinking about it 14:43:46 <njohnston> OK, I will respond to the author 14:44:04 <njohnston> #action njohnston to respond to http://lists.openstack.org/pipermail/openstack-dev/2016-June/098207.html and suggest RFE 14:44:30 <njohnston> My only other items is that I will be out on PTO next week (7/6), as well 7/27 14:45:27 <slaweq> may I have one question? 14:45:35 <njohnston> slaweq: By all means, go ahead 14:45:43 <slaweq> it's about https://review.openstack.org/#/c/303626/ - I back to work on it littlebit 14:45:50 <slaweq> and I have problem with db upgrades 14:46:20 <slaweq> if I want to add "direction" column to bw_limit rules I need to remove unique constraint for qos_policy_id fk 14:46:35 <slaweq> and add unique constraint for pair policy_id - direction 14:46:41 <ihrachys> slaweq: right 14:46:47 <slaweq> and there is some problem with such upgrade in pgsql 14:47:10 <slaweq> maybe someone of You could take a look on that and help me 14:47:22 <ihrachys> slaweq: logs? 14:47:39 <slaweq> db upgrade is going fine 14:47:48 <slaweq> but functional test is not passing 14:48:04 <slaweq> because unique constraint for qos_policy_id is not removed in pgsql 14:48:20 <ihrachys> do you use remove_foreign_keys ? 14:48:21 <slaweq> so there is no match between alembic scripts and model 14:48:21 <njohnston> I see. 14:48:26 <slaweq> yes 14:48:30 <njohnston> AssertionError: Models and migration scripts aren't in sync: 14:48:30 <njohnston> [ ( 'remove_constraint', 14:48:30 <njohnston> UniqueConstraint(Column('qos_policy_id', VARCHAR(length=36), ForeignKey(u'qos_policies.id'), ForeignKey(u'qos_policies.id'), ForeignKey(u'qos_policies.id'), ForeignKey(u'qos_policies.id'), table=<qos_bandwidth_limit_rules>, nullable=False)))] 14:48:42 <slaweq> and this function is not fine even for mysql 14:48:54 <slaweq> because if You are removing fk, unique constraint is not removed 14:49:14 <slaweq> so for mysql You need to remove fk and then remove unique constraint 14:49:14 <ihrachys> slaweq: you probably want to ask HenryG 14:49:31 <slaweq> ihrachys: ok, that tip I expected :) 14:49:34 <slaweq> thx a log 14:49:36 <slaweq> *lot 14:49:48 <slaweq> so that's all from my side 14:50:29 <njohnston> Does anyone have anything else? 14:50:47 <njohnston> I'll be interested to see what QoS-related talks are proposed for Barcelona. 14:51:57 <davidsha> I was thinking of doing an OpenFlow talk, what it is, what it can do how to use it. Would probably touch on the flow manager too. 14:52:21 <njohnston> davidsha: Nice. 14:53:22 <njohnston> OK, I think that's it... have a lovely day everyone. 14:53:26 <njohnston> #endmeeting