14:03:47 <ajo> #startmeeting neutron_qos
14:03:48 <openstack> Meeting started Wed Mar  9 14:03:47 2016 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:52 <openstack> The meeting name has been set to 'neutron_qos'
14:04:09 <ajo> Hi, let's start by the features report
14:04:26 <ajo> #topic features report
14:04:37 <ajo> RBAC and LB/bwlimiting are merged
14:04:58 <ajo> and we have DSCP still waiting to be decided
14:05:44 <ajo> armax identified that neutronclient for DSCP required an exception, and that's still being decided, I need to talk to dhellmann when he's back around
14:06:10 <ajo> for testing, we require that to include fullstack tests in the release
14:06:27 <ajo> and also, it's of course, important for people to be able to use the feature
14:06:41 <ajo> although they could bump their clients to 4.2.x , that wouldn't be ideal
14:06:56 <ajo> I think armax worry was mostly about quality assurance, so I want to talk with him again today too
14:07:04 * ajo looks for the mail list link
14:07:40 <jschwarz> ajo, sorry, I misunderstood - the fullstack tests should be merged before the GA as well?
14:08:19 <ajo> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/088717.html
14:08:40 <ajo> I think that's what armax means, but may be his quality concern was more about making server side available, and not neutron client
14:08:53 <ajo> IMHO, the neutronclient change is so orthogonal to anything else, that it's safe
14:09:14 <ajo> but getting a feature in in RC needs their exception approval
14:09:24 <ajo> vhoward, thoughts?
14:09:43 <ajo> jschwarz, did I answer your question ^?
14:09:48 <jschwarz> ajo, yes
14:10:03 <ajo> ihrachys, any extra thoughts on this ^  ?
14:10:36 <ajo> for testing-sake, amotoki provided an alternative option which could satisfy the fullstack part: http://lists.openstack.org/pipermail/openstack-dev/2016-March/088784.html
14:11:36 <ihrachys> ajo: no thoughts, just praying
14:11:52 <ajo> ihrachys, I pray to my computer via keyboard :D
14:11:52 <amotoki> in my understanding, we have two client libs for testing: tempest-lib and python-*client.
14:12:08 <ajo> amotoki, correct, tempest-lib is covered, and included within the patch
14:12:32 <ajo> along with API testing
14:12:34 <amotoki> are we using python-*client for fullstack testing?
14:12:39 <ajo> yes
14:12:59 <ajo> jschwarz, ^ could it make sense, to move to our own tempest-lib in the future to avoid issues like this?
14:13:05 <amotoki> what is the direction? do we support both?
14:13:14 <ajo> or do we want to test python-neutronclient specifically
14:13:19 * jschwarz is still reading the mail
14:13:21 <ajo> which, can make sense as a "full" stack
14:13:43 <ajo> amotoki, tempest tests always used their tempest lib, and we inherited that in the API-tests ,
14:14:01 <ajo> I guess they had this kind of dependency issue in the past
14:14:10 <jschwarz> amotoki, we're using python-neutronclient specifically in fullstack
14:14:12 <amotoki> in my understanding, the reason tempest-lib has its own client is because we need to test API itself.
14:14:17 <ajo> but I guess that also makes sense to have fullstack testing the client, as it's part of the standard stack
14:14:37 <jschwarz> amotoki, granted, fullstack was written before tempest-lib so it might make sense to revisit this now
14:15:00 <ajo> jschwarz, ok, may be something we could discuss in next neutron meetings
14:15:05 <ajo> or over the ML
14:15:14 <jschwarz> ajo, agreed. I'll ping amuller over it and see what he thinks
14:15:30 <amotoki> jschwarz: thanks. i didn't know the full story of fullstack.
14:15:36 <slaweq_> hello, sorry for late
14:15:48 <ajo> amotoki, jschwarz , but to be faird, regardless of the dependency,  fullstack is adding extra testing to neutronclient, which tempest does not
14:15:59 <ajo> faird? .. fair
14:16:17 <ajo> hi slaweq_ :)
14:16:27 <jschwarz> yes. but if tempest-lib can be used to streamline such processes of adding new features...
14:16:36 * jschwarz is not very familiar with tempest-lib
14:16:38 <amotoki> I think it depends on the purpose of fullstack tests.
14:16:49 <ajo> yes
14:17:00 <ajo> if we want to keep neutronclient within it's scope, or not,
14:17:06 <ajo> we also have openstack cli ;)
14:17:27 <amotoki> I agree that we need more testing for neutronclinet as python SDK.
14:17:38 <jschwarz> amotoki, from what I understand from my brief look at the github, it looks like tempest-lib merely runs the CLI of neutronclient - am I mistaken?
14:18:13 <jschwarz> ah I just found the services/network/ library
14:18:22 <jschwarz> #link https://github.com/openstack/tempest-lib/tree/master/tempest_lib/services/network
14:18:38 <amotoki> jschwarz: though I am talking about tempest api test or tempest-lib, they have several portions: API tests, CLI tests.
14:18:38 <ajo> ok, so let's talk to dhellman and armax, amotoki,  I will ping you for just in case you can join that conversation (#openstack-release  / #openstack-neutron) when it happens,
14:19:13 <njohnston> ajo: I'd like to piggyback as well
14:19:20 <ajo> hi njohnston,
14:19:27 <jschwarz> I think we all agree there's an added bonus in using python-neutronclient for the end-to-end testability it gives
14:19:34 <ajo> any strong point to help me convince them to get the neutronclient/feature in ?
14:19:38 <jschwarz> anyway I'll bring it to amuller's office
14:19:46 <jschwarz> ajo, yes.
14:19:52 <ajo> IMHO you have all made a good work making things U/S now, and collaborating into other needs for the feature to exist
14:20:07 <ajo> and that makes me think it's nicer to have in M than start-of-N
14:20:18 <jschwarz> ajo, previously (in the first version of QoS) the neutronclient patches didn't need a FFE (as far as I remember - ihrachys seems to disagree with me)
14:20:36 <ihrachys> jschwarz: I don't disagree
14:20:38 <amotoki> from user perspective, it is nicer to be a part of M :)
14:20:40 <jschwarz> ajo, also testing code can definetely be pushed back to near-RC
14:20:45 <jschwarz> ah! :)
14:20:52 <ihrachys> jschwarz: I only think that assuming procedures are not changed is not correct
14:21:01 <ajo> amotoki: yes, as it's ready
14:21:05 <jschwarz> ihrachys, ack
14:21:28 <jschwarz> anyway ajo you might be able to play on the "previously we didn't need a FFE for the python-neutronclient - why now?" card
14:21:28 <amotoki> anyway I will review client patches
14:22:29 <ajo> jschwarz, yes, that freeze is something does not fully convince me, but , I understand their reasons for doing it
14:22:42 <jschwarz> ajo, me too. but it's leverage XD
14:22:56 <ajo> amotoki, thanks: the only thing it does is refactoring some bw-limiting-rule (qos) parts, but it seems safe to me
14:23:13 <ajo> amotoki, outside of it's only scope for existence :)
14:23:37 <ajo> #link https://review.openstack.org/#/c/254280
14:23:50 <ajo> dhellmann, ^  when you're around
14:24:12 <ajo> dhellmann, it's all about http://lists.openstack.org/pipermail/openstack-dev/2016-March/088717.html
14:24:45 <ajo> so, probably we must jump to next topic
14:25:03 <ajo> I wanted to ask for some clarifications on the ECN RFE
14:25:10 <ajo> #topic RFEs
14:25:30 <ajo> I asked some questions about ECN here:
14:25:32 <ajo> #link https://etherpad.openstack.org/p/QoS_ECN
14:25:50 <ajo> and here:
14:26:03 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1505627
14:26:03 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Confirmed] - Assigned to Reedip (reedip-banerjee)
14:26:03 <ajo> comment 11
14:26:15 <ajo> but still waiting for answer, sorry it took me to long to get into this RFE.
14:26:33 <ajo> vikram_, reedip_away are you around?
14:27:05 <njohnston> Also, as I recall from the RFC the ECN bit to be used is a negotiated thing, isn't it?
14:27:27 <njohnston> as in, is this side using ECT(0) or ECT(1)
14:27:53 <ajo> njohnston, and when negotiated, to notify the other side about congestion too
14:28:16 <ajo> the idea is that instead of dropping the packet, you let it in, and on the ACK you set the ECN flag
14:28:23 <ajo> (for TCP)
14:28:32 <ajo> and the other end throttles
14:28:45 <ajo> and as far as I understood, anything in the middle can raise the flag for packets
14:28:58 <ajo> but it has to be raised in the sender direction
14:29:08 <ajo> on subsequent packets
14:29:11 <ajo> if I didn't get it wrong
14:29:32 <ajo> but I would like confirmation since I'm not an expert on the matter
14:29:44 <ajo> also, It's unclear to me how would it be implemented, but that would be more matter of a spec
14:30:52 <irenab> ajo: this may need ToP support as well
14:30:56 <njohnston> Read RFC3168 section 6.1.1 to see how it should be implemented for negotiating ECN-capable connections: https://tools.ietf.org/html/rfc3168#section-6.1.1
14:31:02 <ajo> irenab, ToP?
14:31:07 <irenab> ToR
14:31:20 <amotoki> I think ajo's understanding is correct in general.
14:31:21 <ajo> ah, ToR could make use of it to flags packets, but it's not necessary
14:31:44 <amotoki> ToR is one of the middle
14:31:45 <ajo> njohnston, I must read it, but yes, it has to be negotiated end to end,
14:32:21 <ajo> if we want to be able to manipulate the bit to flag over-bandwidth
14:32:27 <ajo> thanks for confirmation amotoki
14:32:59 <ajo> ok, could it make sense to say: let's ask for a spec on this?
14:33:08 <ajo> so they can provide more details of how they plan to implement it?
14:33:33 <njohnston> Absolutely.
14:33:46 <ajo> amotoki, btw, thanks for joining, I know it's a very bad hour in your TZ :)
14:34:04 <irenab> ajo: I think if the use case is clear, asking for the sopec is reasonable step
14:35:00 <ajo> amotoki, njohnston , irenab , ok I will explain in the RFE and so next time this is to be looked at in drivers meeting, they can verify it's in good state to ask for spec work.
14:35:05 <amotoki> ajo: np though it is around 2330. I am waiting for the start of live TV program of cycling road rase (paris to nice)
14:35:14 <ajo> :D amotoki
14:35:18 <njohnston> Also, why does it say, "but this will be a redundant effort" in https://bugs.launchpad.net/neutron/+bug/1505627 ?
14:35:18 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Confirmed] - Assigned to Reedip (reedip-banerjee)
14:35:30 <ajo> redundant?
14:35:56 <njohnston> "Though each hosts can use IP header TOS ECN bit functionality to implement explicit congestion notification [1]_ but this will be a redundant effort." <- from the first paragraph of the bug report
14:36:17 <ajo> I don't know
14:36:17 <njohnston> I did not grok the 'redundant' part
14:37:35 * dhellmann reads some scrollback
14:38:02 <ajo> hi dhellmann , may be I can give you a reduced version
14:38:07 <ajo> thanks for reading,
14:38:53 <ajo> One of the features that the people from comcast and intel have been working on (QoS/DSCP marking) depends on the neutronclient support (for testability, -we could workaround that-, and for user experience : availability of the client bits)
14:39:23 <ajo> The have been working on that for like 5 cycles, and they have made a hard work to get that happening the upstream way
14:39:56 <ajo> in a generic enough way so we could construct a good QoS api, instead of an scattered one
14:40:11 <ajo> and they also helped in making agents extensible, etc... paying lots of technical debt in the way
14:40:20 <dhellmann> I appreciate the amount of effort involved
14:40:22 <ajo> I understand the reasons of freeze
14:40:37 <ajo> the neutron client patch is quite orthogonal to anything else
14:40:51 <ajo> and I believe it would not introduce any risk
14:41:05 <dhellmann> the problem is that we have other projects that depend on neutron client, and the requirements are under freeze right now to avoid introducing uncertainty into the build system while we finalize feature work on all projects
14:41:56 <ajo> dhellmann, but no other projects are using the specific features this patch adds
14:42:08 <dhellmann> ajo : but they use neutronclient
14:42:44 <dhellmann> and this work would require a new release, and changing the constraints file
14:42:51 <dhellmann> both of those are frozen except for bugs right now
14:43:29 <ajo> dhellmann, yes, that's why we were asking for an exception
14:43:47 <dhellmann> I count 57 different projects that have neutronclient in requirements file
14:43:56 <dhellmann> ajo: I'm trying to explain why I do not want to give you that exception. :-/
14:44:40 <dhellmann> is there any reason the service feature can't land without the client update?
14:44:52 <ajo> dhellmann, armax was against it (as far as I understood)
14:44:53 <ihrachys> dhellmann: no strict reason
14:45:10 <ajo> but may be he was refering just on testing
14:45:21 <dhellmann> ok, I can see his perspective on that
14:45:21 <ajo> I may need to clarify that with him as soon as he's online
14:45:57 <ajo> I guess his concern would be providing a the server feature, with no client side, but at least the interested parties could start making use of it via API
14:46:07 <dhellmann> if the team decides the feature can land without the client update, then you could prepare a new feature release of the client from master soon after we unfreeze releases and requirements
14:46:25 <dhellmann> that release would be part of newton, not mitaka, but it would at least give you a release to work with
14:46:28 <amotoki> ajo: can we implement a specific part we need for testing   by using put/post/delete/get directly?
14:47:05 <ajo> amotoki, for that think it would be enough to use our neutron testing upper-contraints
14:47:09 <dhellmann> if the team decides that both parts of the feature need to land around the same time, then I'm not sure I see another good path forward
14:47:10 <ihrachys> amotoki: it's not about testing, it's about what we claim to be the official mitaka client version (which will not include bits to work with some parts of mitaka server)
14:47:20 <ajo> dhellmann, thanks for your input, and patience
14:47:40 <dhellmann> ajo: sure, I'm sorry the timing worked out the way it did
14:47:41 <ihrachys> ajo: dhellmann: I guess we need to get back to armax with 'partial' proposal
14:47:43 <amotoki> ihrachys: got it
14:47:59 <njohnston> In my view, partial is better than nothing
14:48:09 <ajo> ihrachys: but still, interested parties could go just via API, as some people do, fi they wanted
14:48:17 <ajo> or bump their neutron client / do a bacport
14:48:20 <ajo> backport
14:48:21 <ihrachys> njohnston: yes. and it's easy to backport dscp to mitaka client
14:48:27 <ihrachys> not in upstream but generally
14:48:33 <ajo> yeah, I mean that
14:48:49 <amotoki> ihrachys: doesn't it violate the backport policy?
14:48:55 <njohnston> I'd rather backport DSCP to mitaka just in python-neutronclient than have to do it in both client and server
14:49:06 <ihrachys> amotoki: that's why not upstream.
14:49:09 <ajo> amotoki, that's why he says "not in upstream" :) but people could do it D/S if they wanted
14:49:15 <ajo> or they could grab the 4.2.x series of the client
14:49:21 <ihrachys> amotoki: but it would be fine for Red Hat or Comcast to backport it to whatever they use
14:49:26 <njohnston> yep
14:49:36 <ajo> or if they talk to API without our client :)
14:49:36 <amotoki> ihrachys: ah... i missed that line.
14:49:40 <ihrachys> backport for something with alembic script is not THAT obvious
14:49:40 <ajo> which is also a perfect valid case
14:49:49 <ajo> yeah
14:50:12 <ajo> D/S backport of server side would be a mess if it's not the first DB thing to land newton
14:50:16 <ajo> or merged in Mitaka-RC
14:51:04 <ajo> ok, I will answer with a link to this discussion in the mail list
14:51:24 <ajo> and propose the approach of merging only the server-side and bumping upper-requiremets to have fullstack in
14:51:38 <njohnston> Sounds good.
14:52:12 <vhoward> ok
14:52:38 <ajo> ok, where were we
14:52:39 <ajo> :)
14:52:46 <ajo> we were talking about ECN
14:53:06 <ajo> #action ajo make a note on the ECN RFE to say it's ok for us to ask for a spec from the RFE workflow.
14:53:25 <ajo> #action ajo fill ingress QoS rate limit RFE
14:53:36 <ajo> #action ajo fille minimum egress bw guarantees RFE
14:53:41 <ajo> #undo
14:53:43 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0xad9a890>
14:53:50 <ajo> #action ajo fill minimum egress bw guarantees RFE
14:54:17 <ajo> davidsha is not around, I was going to ask for the status of:
14:54:20 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1505627
14:54:20 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Confirmed] - Assigned to Reedip (reedip-banerjee)
14:54:42 <ajo> sorry
14:54:50 <ajo> #undo
14:54:51 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0xaba0610>
14:55:09 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1527671
14:55:09 <openstack> Launchpad bug 1527671 in neutron "[RFE]Neutron QoS Priority Queuing rule" [Wishlist,Triaged]
14:55:30 <ajo> probably in next meeting we should start talking of prioritization of next cycle
14:55:40 <ajo> so we can share that with the drivers team.
14:55:46 <ajo> and see what they think.
14:56:12 <irenab> ajo: it worth to meniton on the RFE is it has dependency on other projects, like nova
14:56:12 <ajo> #topic Free discussion
14:56:29 <ajo> irenab, the BW guarantees one? , yes
14:56:36 <irenab> yes
14:56:51 <ajo> specifically with (if lucky) generic resource pools, and scheduling
14:56:52 <slaweq_> guys
14:56:58 <slaweq_> I want to ask about bug https://bugs.launchpad.net/neutron/+bug/1507761
14:56:58 <openstack> Launchpad bug 1507761 in neutron "qos wrong units in max-burst-kbps option (per-second is wrong)" [Low,Confirmed] - Assigned to Slawek Kaplonski (slaweq)
14:57:08 <ajo> hi slaweq_ :)
14:57:16 <ajo> how's that going?
14:57:36 <slaweq_> I'm not sure if would be better to change parameter name to max_burst_kb or maybe remove units from those names at all?
14:57:52 <slaweq_> ajo: hi, I just starting to work on this
14:57:58 <slaweq_> I had no time before
14:58:16 <ajo> kb can be confused to "kilobyte"
14:58:21 <ajo> I'd say max_burst_kbits
14:58:27 <ajo> oposed to the current max_burst_kbps
14:58:30 <ajo> opposed
14:58:39 <slaweq_> yep
14:58:45 <njohnston> +1 kbits - just saying "kb" will be interpreted by the viewer however they want
14:58:58 <slaweq_> I don't know it will be confued, kbytes would be kB
14:59:07 <slaweq_> but ok, thx for Your opinion :)
14:59:10 <ajo> yeah
14:59:14 <slaweq_> so I know what to do now
14:59:20 <ajo> kbytes is kB, but still...
14:59:25 <ajo> slaweq_++
14:59:32 <slaweq_> ok, so thx
14:59:32 <ajo> so, I guess we should wrap up, it's the top of the hour
14:59:39 <ajo> thanks everybody for joining
14:59:43 <vhoward> o/
14:59:50 <ajo> #endmeeting