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