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