14:01:38 <slaweq> #startmeeting neutron_qos
14:01:39 <openstack> Meeting started Wed Nov 16 14:01:38 2016 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:41 <slaweq> hello
14:01:43 <openstack> The meeting name has been set to 'neutron_qos'
14:01:46 <ralonsoh> hi
14:02:28 <slaweq> I think we will wait few minutes for people
14:02:49 <ralonsoh> I read ajo and njonshon are not going to attend
14:02:52 <davidsha> Hi
14:03:04 <slaweq> ralonsoh: I think ajo will be but later
14:03:11 <ajo> hi o/ ;) I was supposed to have a meeting which moved, but slaweq has been preparing the meeting, I'll let him do the honours, very grateful that you could help slaweq
14:03:22 <slaweq> ajo: thx
14:03:31 <slaweq> but I hope You will help me with it :)
14:03:34 <ajo> of course
14:03:41 <slaweq> ok, so can we start?
14:04:04 <slaweq> or we are waiting for someone else?
14:04:19 <ralonsoh> go on, I think
14:04:23 <slaweq> ok
14:04:24 <slaweq> #topic RFEs-approved
14:04:42 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1586056
14:04:42 <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:04:48 <slaweq> first rfe-approved
14:05:23 <slaweq> it is still waiting for qos_notification refactor which ajo is doing:  https://review.openstack.org/#/c/351858/
14:05:37 <ajo> oh, a note about this one
14:05:39 <slaweq> so I have nothing to add here
14:05:44 <ajo> I'm abandoning that patch in favor of:
14:06:00 <ajo> https://review.openstack.org/#/c/396651/
14:06:08 <ajo> #link https://review.openstack.org/#/c/396651/
14:06:13 <ralonsoh> I'll review this patch today
14:06:13 <slaweq> ah, right, I forgot to change this link
14:06:22 <ralonsoh> ajo's patch
14:06:34 <davidsha> Same, is it meant to be work flow -1?
14:06:37 <ralonsoh> ajo: or is still wip?
14:06:48 <ajo> thanks ralonsoh I will submit a new version after meeting, I was cleaning some pep8's and also adressing https://bugs.launchpad.net/neutron/+bug/1627749 partly, at the same time
14:06:48 <openstack> Launchpad bug 1627749 in neutron "qos driver api can have better error handling" [Medium,Confirmed] - Assigned to Miguel Angel Ajo (mangelajo)
14:07:02 <ralonsoh> I'll wait
14:07:16 <ajo> ralonsoh, next version will be ready (just missing testing changes)
14:07:25 <slaweq> ajo: I will also try to review it asap
14:07:33 <ajo> thank you ralonsoh & slaweq
14:08:16 <slaweq> ok so moving on, next one: https://bugs.launchpad.net/neutron/+bug/1560961
14:08:16 <openstack> Launchpad bug 1560961 in neutron "[RFE] Allow instance-ingress bandwidth limiting" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:08:37 <slaweq> this one depends on extended validation so is also blocked by ajo's patch :)
14:08:47 * ajo blocks the world ':]
14:09:04 <slaweq> ajo: maybe not whole world but QoS part :P
14:09:23 <ralonsoh> as soon as ajo's patch is up, I'll review that too
14:09:28 <slaweq> I saw that https://bugs.launchpad.net/neutron/+bug/1560963 is finished already
14:09:28 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,Fix released] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:09:36 <slaweq> thx ralonsoh
14:09:53 <ajo> '':]
14:10:03 <ralonsoh> Minimum bandwidth support: SRIOV merged, LB under review!!
14:10:05 <ralonsoh> one sec
14:10:15 <ralonsoh> https://review.openstack.org/#/c/357865/
14:10:34 <slaweq> I already reviewed this patch :)
14:10:37 <ralonsoh> slaweq is taking care of the reviews! thanks!
14:10:37 <ajo> #link https://review.openstack.org/#/c/357865/
14:11:05 <ajo> oh right, and the OVS part was in WIP, is that correct?
14:11:24 <ralonsoh> yes... I don't know if I can implement it
14:11:32 <ralonsoh> too many problems
14:11:38 <slaweq> ralonsoh: I think I can help You on that maybe
14:11:39 <ajo> ralonsoh, it got more complicated than expected?
14:11:41 <ralonsoh> and architecture issues
14:11:53 <ralonsoh> yes, a lot of more
14:11:55 <ajo> ok, may be we can discuss that one for Pike and help
14:12:00 <ajo> lot of things in our plates
14:12:02 <ralonsoh> I agree
14:12:42 <slaweq> ralonsoh: is there patch already on gerrit?
14:12:58 <ralonsoh> #link https://review.openstack.org/#/c/318531/
14:13:02 <ralonsoh> But WIP
14:13:13 <slaweq> and btw. I think that bug https://bugs.launchpad.net/neutron/+bug/1560963 shouldn't be "fix released", am I right?
14:13:13 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,Fix released] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:13:46 <ralonsoh> The initial spec was SRIOV only
14:13:51 <ralonsoh> We added LB and OVS
14:14:33 <ralonsoh> Go on, we can talk about this by mail
14:14:40 <slaweq> ok
14:14:47 <slaweq> so there is one more: https://bugs.launchpad.net/neutron/+bug/1578989
14:14:47 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,Confirmed]
14:15:01 <slaweq> which is not assigned to anyone yet
14:15:05 <ajo> I pushed a spec for this one: https://review.openstack.org/#/c/396297/2
14:15:19 <ajo> so we can discuss the technical details, and integration details with nova
14:15:30 <slaweq> #link https://review.openstack.org/#/c/396297/2
14:15:41 <slaweq> ajo: ok, I will try to review it also
14:15:46 <ajo> we need to involve the nova guys to have a look on the integration details, and chunk it into work items. ralonsoh took one already
14:16:06 <ralonsoh> About this spec: should we create new specs for sub-tasks?
14:16:37 <ajo> ralonsoh, no, you just reference the spec from your patches
14:16:44 <ralonsoh> ok, perfect
14:16:44 <davidsha> you could file a bug to expand it right?
14:16:51 <ajo> but we need a blueprint created for it
14:16:52 <ralonsoh> Yes, I think so
14:17:07 <ajo> I guess drivers could help with that.
14:17:08 <slaweq> yes, agree with blueprint
14:17:18 <ajo> amotoki,  ^
14:17:20 <slaweq> to aggregate all such patches
14:17:36 <amotoki> ajo: what?
14:17:43 <ajo> amotoki, : https://review.openstack.org/#/c/396297/2 this is from an approved RFE https://bugs.launchpad.net/neutron/+bug/1578989
14:17:43 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,Confirmed]
14:17:53 <ajo> we thought that the feature is complex and has many integration points with nova,
14:18:03 <ajo> so we thought a spec + blueprint fits it best
14:18:18 <ajo> can we get/or create ourselves the blueprint and keep rolling?
14:18:23 <amotoki> ajo: is there no corresponding blueprint?
14:18:57 <ajo> amotoki, just the approved RFE, and the spec that we decided was useful to coordinate neutron/nova and work items
14:19:23 <amotoki> ajo: we can create a blueprint for an approved RFE if it needs a discussion or it require a lot of effort.
14:19:36 <ajo> amotoki, it's exactly that case
14:19:48 <amotoki> ajo: what can I help you?
14:19:55 <ajo> (lot multi-cycle effort and integration with nova)
14:20:11 <ajo> amotoki, can I go ahead and create the blueprint myself or should I get it asked in the drivers meeting?
14:20:27 <ajo> or may be create, and just mention it in driver's ?
14:21:16 <amotoki> you can create a bp and let the driver team know so that they can assign a approver (= a sponsor) and set other fields.
14:21:31 <ajo> I can take the approver part
14:21:41 <ajo> ack, thanks amotoki
14:21:52 <ajo> #action ajo creates the blueprint and mentions it on drivers meeting
14:22:01 <ralonsoh> thanks!
14:22:03 <slaweq> ok thx ajo
14:22:06 <amotoki> great!
14:22:08 <ajo> thank you all
14:22:18 <slaweq> anything to add?
14:22:44 <slaweq> if not, we are going forward
14:22:51 <slaweq> #topic RFEs
14:23:06 <slaweq> there is also 2 not approved rfe
14:23:12 <slaweq> https://bugs.launchpad.net/neutron/+bug/1505627
14:23:12 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Incomplete] - Assigned to Reedip (reedip-banerjee)
14:23:26 <slaweq> this one is quite old as I remember
14:23:44 <slaweq> reedip_: are You doing something with it?
14:24:16 <reedip_> slaweq : Hi , I had a spec but its not yet complete
14:24:25 <reedip_> its pretty slow
14:24:33 <davidsha> reedip_: do you have a link?
14:24:45 <reedip_> davidsha : not yet, I have it in my own repo
14:25:00 <reedip_> not in gerrit yet
14:25:00 <davidsha> reedip_: kk
14:25:43 <slaweq> so there is one more: https://bugs.launchpad.net/neutron/+bug/1634798
14:25:43 <openstack> Launchpad bug 1634798 in neutron "[RFE] Qos DSCP to vlan priority mapping" [Undecided,New]
14:25:50 <slaweq> which is new
14:26:42 <slaweq> I think it should be discussed on drivers meeting, right?
14:26:42 <ajo> I wonder
14:26:49 <ajo> if this doesn't really need to be done
14:26:49 <davidsha> slaweq: its a resurrection of the vlan pcp one is it?
14:26:58 <ajo> or yes
14:27:11 <ajo> if what they mean is translating DSCP (send by the VM) into VLAN q priority
14:27:30 <ajo> because if what they mean is translating policies DSCP into VLAN q , they could just add a VLAN q rule, when we had that
14:27:36 <ajo> I'm going to ask in the RFE
14:28:12 <slaweq> ajo: You mean add new qos_rule type, right?
14:28:13 <davidsha> ajo: I think thats it. pcp is a 0-7 value if memeory serves so you would be matching on traffic classes I guess.
14:29:05 <ajo> yes, davidsha and we also have the DEI bit (drp eligible indicator)
14:29:08 <ajo> drop
14:29:36 <ajo> but it's 3 bits, correct
14:29:40 <ajo> there was another RFE for that
14:30:22 <davidsha> kk, thanks.
14:30:56 <slaweq> so ajo will ask in RFE about details, right?
14:31:02 <ajo> done, asked
14:31:06 <slaweq> thx ajo
14:31:18 <slaweq> next topic is
14:31:22 <slaweq> #topic Bugs
14:32:02 <slaweq> https://bugs.launchpad.net/neutron/+bug/1639186
14:32:03 <openstack> Launchpad bug 1639186 in neutron "qos max bandwidth rules not working for neutron trunk ports" [Low,Confirmed] - Assigned to Luis Tomas Bolivar (ltomasbo)
14:32:22 <slaweq> I don't know if owner of this bug is here
14:32:45 <slaweq> ltomasbo: is it Your bug?
14:33:39 <ajo> I believe ltomasbo is offline, travelling to Munich
14:33:49 <slaweq> ok, so next one
14:33:53 <ajo> I can update
14:34:03 <ajo> He was looking into max bw compatibility with trunk ports and subports
14:34:16 <ajo> and he found that subports can't be limited, because those are patch-port based
14:34:27 <ajo> ralonsoh,  ^ I guess that rings a bell ':D
14:34:40 <ralonsoh> yes, I know
14:34:49 <ajo> so he was looking into the posibility of having veths dynamically created for those cases
14:34:59 <ajo> but that would not work in the case of DPDK I believe
14:35:06 <ralonsoh> no, not in DPDK
14:35:08 <ajo> but it could be useful to the container use cases
14:35:39 <ajo> so, he's investigating
14:35:42 <ajo> (done)
14:36:00 <slaweq> thx ajo
14:36:04 <slaweq> next one: https://bugs.launchpad.net/neutron/+bug/1616547
14:36:04 <openstack> Launchpad bug 1616547 in neutron "qos: rule api definition shouldn't include tenant_id" [Low,Incomplete]
14:36:13 <slaweq> I don't know if this is still valid
14:36:23 <ralonsoh> I thinks this is solved
14:36:25 <slaweq> I remember that some time ago there was some discussion about it
14:36:26 <ralonsoh> but I'll check
14:36:37 <slaweq> ralonsoh: thx
14:36:50 <slaweq> https://bugs.launchpad.net/neutron/+bug/1627749
14:36:50 <openstack> Launchpad bug 1627749 in neutron "qos driver api can have better error handling" [Medium,Confirmed] - Assigned to Miguel Angel Ajo (mangelajo)
14:36:59 <slaweq> I think ajo told at the beginning that he is working on it
14:37:29 <slaweq> right ajo?
14:37:38 <slaweq> something to add here?
14:37:38 <ajo> yes, I'm chasing that as part of it, one sec let me push my current state
14:37:47 <ajo> so we can show a link to what specifically I'm doing
14:38:51 <ajo> #link https://review.openstack.org/#/c/396651/5/neutron/services/qos/qos_plugin.py@84
14:38:59 <ajo> #link https://review.openstack.org/#/c/396651/5/neutron/services/qos/qos_plugin.py@117
14:39:04 <ajo> #link https://review.openstack.org/#/c/396651/5/neutron/services/qos/qos_plugin.py@141
14:39:05 <ajo> etc ..
14:39:21 <ajo> at least with this, if one driver fails, (backend unavailable or something)
14:39:38 <ajo> we go on and notify the others
14:39:50 <ajo> ideally we could revert the DB and the plugins that worked
14:39:51 <ajo> but...
14:39:54 <ajo> my thinking was
14:39:54 <slaweq> ok, so it's related to You "big blocker" patch :)
14:40:07 <ajo> what if the other drivers won't revert or fail to revert?
14:40:14 <ajo> lol
14:40:20 <ajo> big blocker patch is a good name for it :]
14:40:26 <slaweq> :D
14:43:06 <reedip_> Hi slaweq , is there an OpenstackCLient for Neutron QoS ? Was going through https://bugs.launchpad.net/neutron/+bug/1640762
14:43:06 <openstack> Launchpad bug 1640762 in neutron "when I update a Qos policy, value of shared can not be changed to false from true" [Undecided,Incomplete] - Assigned to Slawek Kaplonski (slaweq)
14:43:25 <slaweq> reedip_ just goes to next one :)
14:43:29 <ajo> ralonsoh, is working hard on OSC :)
14:43:37 <slaweq> which I wanted to talk now
14:43:39 <slaweq> thx reedip_
14:43:52 <ralonsoh> #link https://review.openstack.org/#/c/352477/
14:43:53 <reedip_> lol
14:43:56 <ralonsoh> waiting for this
14:44:04 <ralonsoh> reviews, I mena
14:44:08 <ralonsoh> mean
14:44:23 <reedip_> Ok, I will bring this up with the OSC :)
14:44:29 <reedip_> Thanks for the patch though
14:44:32 <ralonsoh> thanks
14:44:38 <slaweq> I think I was fixing something like that in neutronclient some time ago
14:44:52 <reedip_> slaweq : which brings up the point that the above bug would be applicable only to NeutronClient , right ?
14:45:07 <slaweq> IMO only in Openstack client
14:45:12 <slaweq> it should be fixed in neutronclient
14:45:16 <ralonsoh> I agree
14:45:25 <slaweq> let me find my patches for that
14:45:37 <reedip_> slaweq : but Neutronclient is deprecated. Should we focus there ?
14:45:50 <reedip_> I would prefer focussing more on OSC migration
14:46:41 <slaweq> about OSC I will check it today and will try to fix it asap
14:47:07 <slaweq> I assigned me to this bug today because I remember that I was doing something like that for neutronclient some time ago
14:47:21 <slaweq> https://review.openstack.org/#/c/327935/
14:47:24 <slaweq> this is it
14:47:50 <slaweq> reedip_: fine for You?
14:48:10 <reedip_> slaweq : I just found the same patch :D
14:48:35 <slaweq> next bug is https://bugs.launchpad.net/neutron/+bug/1640767
14:48:35 <openstack> Launchpad bug 1640767 in neutron "Create a qos-policy , name attribute is necessary when using openstack command line interface, and it become non essential option when I use API or curl command to create" [Undecided,Incomplete] - Assigned to Slawek Kaplonski (slaweq)
14:48:42 <slaweq> I wanted to talk about this one
14:48:45 <reedip_> slaweq : so -no-shared is different from the -shared option, so it means that the bug is expected ..
14:49:00 <reedip_> slaweq : yes, that was another bug I was going to bring up :D
14:49:41 <slaweq> reedip_: there is --no-shared option added if You want to update policy to be shared=False
14:49:54 <reedip_> ok
14:49:58 <slaweq> it is like that instead of --shared=True or --shared=False
14:50:20 <slaweq> so about https://bugs.launchpad.net/neutron/+bug/1640767
14:50:20 <openstack> Launchpad bug 1640767 in neutron "Create a qos-policy , name attribute is necessary when using openstack command line interface, and it become non essential option when I use API or curl command to create" [Undecided,Incomplete] - Assigned to Slawek Kaplonski (slaweq)
14:50:41 <slaweq> if You are creating QoS policy via OSC or neutronclient it must have name given
14:50:50 <slaweq> but Neutron API not require it
14:51:05 <slaweq> so You can create policy without name for example with curl
14:51:28 <slaweq> and now question is: which way to fix it You preffer? fix OSC and neutronclient or change neutron API?
14:51:42 <slaweq> ajo: what do You think about it?
14:51:44 <ajo> hmm,
14:51:51 <ajo> we can also create ports without names
14:51:54 <ajo> or networks without names
14:51:55 <ralonsoh> It's fine. You can use the ID
14:51:55 <ralonsoh> But OSC won't allow this
14:51:57 <ajo> and just depend on the ID
14:52:01 <reedip_> ralonsoh : I had a similar problem with aothr bug
14:52:04 <ajo> so I think there's nothing wrong with the API
14:52:04 <reedip_> just a minute
14:52:26 <slaweq> for me it is something to fix on client side
14:52:33 <slaweq> but I wanted to ask about opinions
14:52:38 <ajo> ye, agreed
14:52:40 <ajo> yeah
14:52:42 <ralonsoh> Agree
14:52:45 <slaweq> ok, thx
14:53:16 <slaweq> reedip_: You wanted to add something?
14:53:59 <slaweq> there is also new bug: https://bugs.launchpad.net/neutron/+bug/1637977
14:53:59 <openstack> Launchpad bug 1637977 in neutron "QoS API parameter name issue, max_burst_kbps should be max_burst_kbits?" [Undecided,New]
14:54:19 <ajo> hmm, we had that before
14:54:24 <ajo> may be in form of RFE
14:54:28 <slaweq> but I think it is something what I reported few months ago and what we decided to not touch because of problems with API versions
14:54:36 <ajo> nothing we can do until the day we have microversioning for API
14:54:36 <slaweq> ajo: it was bug reported
14:54:46 <slaweq> so should we close it now?
14:54:50 <reedip_> Hi, found this
14:54:50 <reedip_> https://review.openstack.org/#/c/250587/
14:54:50 <reedip_> I dont know, but I found amotoki's point a bit valid here
14:54:50 <reedip_> comment# 4
14:54:51 <slaweq> or postpone it?
14:55:15 <ajo> it's a duplicate of https://bugs.launchpad.net/neutron/+bug/1507761
14:55:15 <openstack> Launchpad bug 1507761 in neutron "qos wrong units in max-burst-kbps option (per-second is wrong)" [Low,Won't fix] - Assigned to Slawek Kaplonski (slaweq)
14:55:26 <slaweq> ajo: exactly :)
14:55:51 <ajo> I marked it as duplicate
14:55:56 <slaweq> ok, thx
14:56:09 <reedip_> slaweq, ajo , ralonsoh : I dont know if you got my earlier message
14:56:52 <ralonsoh> reedip_: yes
14:56:56 <ralonsoh> one sec
14:57:37 <ralonsoh> reedip_ I need to read it slowly, not now
14:57:50 <slaweq> yes, I will also read it later
14:58:21 <slaweq> #action read comments on https://review.openstack.org/#/c/250587/
14:58:35 <slaweq> ok, I think that this is all bugs
14:58:41 <slaweq> #topic Open discussion
14:58:49 <slaweq> anyone have got anything else to add?
14:58:55 <ralonsoh> I'm ok
14:58:56 <slaweq> we have 2 minutes more I think
14:59:00 <reedip> damn problem with my home PC , sending the messages late
14:59:39 <ajo> I agree with you reedip , api & client must match in capabilities
14:59:52 <reedip_> just wanted to say that as per an earlier bug discussion with amotoki,  as a convention, neutron CLI requires one required argument.
14:59:52 <reedip_> If all options are optional in the API level and we have 'name' field, we usually use 'name' as a required parameter.
14:59:53 <ajo> but I guess it's not an easy fix on neutron client, may be
15:00:34 <slaweq> ok, thx everyone
15:00:37 <slaweq> #endmeeting