14:00:51 <njohnston> #startmeeting neutron_qos
14:00:51 <openstack> Meeting started Wed Jul 13 14:00:51 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:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:54 <openstack> The meeting name has been set to 'neutron_qos'
14:00:56 <njohnston> ok, that's better
14:01:06 <slaweq> hello
14:01:07 <njohnston> #chair ajo
14:01:07 <openstack> Current chairs: ajo njohnston
14:01:13 <davidsha> Hey
14:01:26 <slaweq> I thought that I missed it when You made "endmeeting" :)
14:01:36 <njohnston> It gets all screwed up when I use the wrong nick
14:01:57 <njohnston> #topic announcements
14:02:06 <njohnston> #link http://releases.openstack.org/newton/schedule.html - N-2 is tomorrow!
14:02:49 <njohnston> I don't know what changes we have that require alterations in python-neutronclient, neutron-lib, etc. but keep in mind those have an earlier close date than everything else
14:03:23 <njohnston> also
14:03:26 <njohnston> I have filed a spec in python-openstackclient to support the QoS commands
14:03:32 <njohnston> #link https://blueprints.launchpad.net/python-openstackclient/+spec/neutron-client-qos
14:03:48 <njohnston> I only went with currently implemented commands in python-neutronclient.  My thought was that once this is in, we can keep up with it as part of the natural course of things.
14:03:54 <njohnston> I'll see if I can get it approved at the openstackclient meeting tomorrow at 1300 UTC.
14:04:21 <davidsha> thanks!
14:04:22 <njohnston> any other announcements?
14:04:23 <slaweq> njohnston: I can help with implementation of it :)
14:05:09 <njohnston> Yes, I am guessing it will be a fair amount of work given the number of commands there are, but I don't know how different the openstackclient environment is from python-neutronclient
14:05:22 <njohnston> ideally things like the tests should be able to copy over pretty seamlessly I hope
14:06:17 <njohnston> #topic RFEs
14:06:26 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1586056
14:06:26 <openstack> Launchpad bug 1586056 in neutron "[RFE] Improved validation mechanism for QoS rules with port types" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:06:37 <njohnston> How goes this one, slaweq?
14:06:45 <slaweq> this one is still waiting for approval
14:06:52 <njohnston> I am distressed that it still doesn't have approval, yes
14:06:57 <slaweq> on last neutron_driver meeting they didn't talk about it
14:07:02 <slaweq> because there was no enough time
14:07:11 <slaweq> I hope that tomorrow it will be discussed
14:07:21 <slaweq> also ajo sent email about it yesterday
14:07:33 <slaweq> so waiting :/
14:07:58 <njohnston> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099107.html Ajo's email on the validation change
14:07:59 <slaweq> btw: njohnston can You change status from "in progress" to "triaged" again?
14:08:19 <njohnston> done
14:08:23 <slaweq> thx
14:09:07 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1560961
14:09:07 <openstack> Launchpad bug 1560961 in neutron "[RFE] Allow instance-ingress bandwidth limiting" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:09:21 <slaweq> this one is in fact waiting for validation of rules
14:09:21 <njohnston> slaweq, looks like you just uploaded a change to work on this: https://review.openstack.org/#/c/341186/
14:09:30 <slaweq> but I'm working on it littlebit
14:09:42 <slaweq> patch for db and API changes is (almost) done
14:09:53 <slaweq> yesterday I started working on ovs implementation also
14:10:06 <slaweq> so it's moving forward slowly
14:10:39 <slaweq> also this one: https://review.openstack.org/#/c/303626/ is related to this RFE
14:11:02 <njohnston> Other than beating the drivers team with a rolled-up newspaper, let us know if there is anything we can to do help.
14:11:37 <slaweq> ok, I will tell You if will be something like that
14:11:43 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1560963
14:11:43 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:11:43 <njohnston> Any notes on this one?
14:12:04 <njohnston> ^^ ralonsoh
14:12:08 <ralonsoh> The spec is almost aproved
14:12:23 <ralonsoh> https://review.openstack.org/#/c/316082/
14:12:27 <njohnston> excellent!  I have been watching the feedback go back and forth
14:13:28 <njohnston> FYI
14:13:29 <njohnston> #link http://tinyurl.com/qos-rfe-unapproved A number of other not-approved RFEs went expired, check it out
14:14:31 <njohnston> #topic Bugs
14:14:46 <njohnston> #link https://bugs.launchpad.net/openstack-manuals/+bug/1600313
14:14:46 <openstack> Launchpad bug 1600313 in openstack-manuals "Using OpenStack Networking with QoS in Networking Guide" [Undecided,In progress] - Assigned to David Shaughnessy (david-shaughnessy)
14:15:06 <njohnston> and
14:15:08 <njohnston> https://launchpad.net/bugs/1588621
14:15:08 <openstack> Launchpad bug 1588621 in openstack-manuals "Using OpenStack Networking with QoS in Networking Guide" [Low,In progress] - Assigned to David Shaughnessy (david-shaughnessy)
14:15:27 <njohnston> are both being taken care of by davidsha, thanks for that!
14:15:37 <davidsha> Hopefully the last PS for those has been put up. No problem!
14:15:39 <njohnston> #link https://review.openstack.org/#/c/339432/
14:16:04 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1515564
14:16:04 <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:16:47 <njohnston> The change to fix this has been going since November https://review.openstack.org/#/c/244680/
14:17:08 <njohnston> it looks like there was something unnecessary put in there, so once that gets removed perhaps this can get merged
14:17:53 <njohnston> and we got a new bug in, which actually has the 'low-hanging-fruit' tag (rare for QoS)
14:17:55 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1600708
14:17:55 <openstack> Launchpad bug 1600708 in neutron "Update ‘--max-kbps’ and ‘--max-burst-kbps’ parameter to 2147483648 or greater than 2147483648 using qos-bandwidth-limit-rule-update command，Neutron server thrown an exception" [Low,Confirmed] - Assigned to QunyingRan (ran-qunying)
14:18:40 <njohnston> it has the low hanging fruit tag, but it looks like it may require a change to the definition of an existing database column... not sure but I think that is a 'contract' migration
14:19:38 <slaweq> if it would be change from signed to unsigned int then maybe not
14:19:43 <slaweq> but I'm not sure
14:19:58 <davidsha> njohnston: this is a change from 32 bit to 64bit
14:20:11 <davidsha> sorry *slaweq
14:20:12 <njohnston> right
14:20:40 <slaweq> ok
14:20:48 <davidsha> it could be a signed 64, or an unsigned 32 atm, since it's non-negative I think it's the latter.
14:20:58 <njohnston> The other point made is, perhaps kbits was a bad choice for units to express this in, in the days of 40 Gb interface cards
14:21:14 <slaweq> njohnston: but how to change it now
14:21:34 <slaweq> and what with existing rules which useres could already create? :)
14:21:46 <davidsha> This is the same problem we had we changing max-burst-kbps to max-burst-kb/
14:22:00 <njohnston> Yeah, I didn't think that comment was especially helpful, it seemed more in the realm of "wistful thinking".
14:22:05 <slaweq> not exactly davidsha
14:22:14 <slaweq> then it was "only" change of option name in API
14:22:28 <slaweq> now is change of meaning for existing values
14:22:40 <slaweq> but maybe adding column with units would be kind of solution?
14:22:56 <slaweq> and kbps would be default for existing records
14:23:05 <slaweq> and new would have different unit
14:23:16 <njohnston> Perhaps.  I see drawbacks to every fix I can imagine.
14:23:35 <davidsha> you would need to make max-kbps and max-burst-kbps return strings then right?
14:24:03 <slaweq> davidsha: probably yes
14:24:33 <slaweq> and also problem with changing names of API parameters then
14:25:37 <slaweq> but maybe it's worth to consider it by ralonsoh on his specs about minimum bw limiting?
14:25:40 <njohnston> You'd almost want to have a new parameter, something that would look like "--max-burst=4mbps" in practice and then parse the unit part of the string.
14:26:17 <slaweq> njohnston: it can be solution IMHO
14:26:18 <ralonsoh> slaweq: ok, so I need to change it again
14:26:33 <slaweq> ralonsoh: I don't know, just saying maybe :)
14:26:45 <ralonsoh> I'll wait for the final decission
14:27:44 <njohnston> Are there other parameters that get expressed as large integers at the command line elsewhere in openstack?  We could see how others do it.
14:28:47 <slaweq> or I have another (maybe stupid) idea: change column type to varchar
14:28:55 <slaweq> and store values as string :)
14:29:26 <njohnston> It makes me think of the -L argument to lvresize: http://linux.die.net/man/8/lvresize
14:29:41 <njohnston> ok, so we definitely don't have consensus on this, let's keep thinking about it
14:29:42 <davidsha> slaweq: would need a lot more validating, but it's an option
14:30:03 <njohnston> #topic Open Discussion
14:30:17 <davidsha> njohnston: would the storage projects have this issue with requesting blocks of memory?
14:30:24 <njohnston> I will be on PTO on 7/27 FYI.
14:30:34 <slaweq> davidsha: I know but then You don't have to change API or something what used can see :)
14:30:58 <njohnston> davidsha: Perhaps, I will check with my ops folks to see what they do with cinder/glance/etc in this regard.
14:31:43 <davidsha> slaweq: true, that's a good point. Also good catch on the dscp follow up patch on missing DSCP_MARK in the functional test!
14:32:01 <slaweq> davidsha: thx
14:32:31 <njohnston> Are any of you going to the neutron mid-cycle?  My travel was denied, sadly.
14:32:34 <slaweq> FYI: I reported presentation about new features in QoS in Newton
14:32:48 <slaweq> together with ajo and ralonsoh
14:32:53 <njohnston> slaweq: Very nice!  Like DSCP! :-D
14:33:14 * njohnston will be in the front row
14:33:19 <slaweq> yes, DSCP is one of new features
14:33:32 <slaweq> njohnston: thx but please vote for it first :)
14:33:41 <njohnston> Of course
14:33:42 <davidsha> Same, looking forward to seeing it!
14:33:47 <ralonsoh> thanks!
14:34:20 <davidsha> We'll ask all the technical DSCP questions >:)
14:34:33 <slaweq> davidsha: no way :P
14:34:50 * njohnston chuckles evilly
14:34:56 <njohnston> OK, that's all I have for today.    Does anyone have anything else?
14:35:37 <davidsha> Oh
14:35:52 <davidsha> PS 2 of the flow classifier is up if people want to check it out
14:36:02 <njohnston> url?
14:36:09 <davidsha> https://review.openstack.org/#/c/323963/
14:36:13 <davidsha> *flow manager
14:36:22 <njohnston> I will definitely take a look
14:36:40 <davidsha> thanks
14:36:41 <slaweq> me also
14:36:45 <ralonsoh> me too
14:37:16 <davidsha> thanks
14:37:26 <njohnston> Also my change to take the l2 agent extension stuff out of l2 and make it general, so there can be l3 agent extensions, is here: https://review.openstack.org/#/c/329701
14:37:49 <njohnston> that has tangential impacts on QoS code, mostly in the form of changing the locations where files are imported from
14:38:47 <slaweq> I will take a look on it too
14:39:18 <njohnston> OK, sounds like we have covered everything.  I'll make sure ajo can cover the next meeting, on 7/27.
14:39:21 <njohnston> Thanks all!
14:39:32 <slaweq> I will not be on next meeting
14:39:32 <njohnston> #endmeeting