14:01:17 #startmeeting neutron_qos 14:01:18 Meeting started Wed May 27 14:01:17 2015 UTC and is due to finish in 60 minutes. The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:20 hi 14:01:23 The meeting name has been set to 'neutron_qos' 14:01:49 #topic summit session 14:01:53 #link https://etherpad.openstack.org/p/YVR-neutron-qos 14:02:01 just a link for anybody who where not able to attend 14:02:16 it was very nice to meet you all (most of you) :) 14:02:41 likewise :) 14:02:47 samehere :) 14:03:01 thanks :) 14:03:16 it seemed like we were all mostly ok with the API, tweaks here and there to be done, but the foundation seemed right 14:03:56 it was good that I managed to understand all the DSCP use cases (like dscp pass through or capping... while I was only thinking of marking) 14:04:34 vhoward and the comcast guys agreed to work in parallel to add an extension spec with DSCP, and OVS support, which should be relatively easy 14:04:56 so, when we get the first part done, we can look into merging DSCP as fast as possible 14:04:58 agree - we may need to tease out more of the policy.json decisions based on some of the feedback at the summmit, but I think we're on the right track 14:05:27 sc68cal, can you elaborate? :) 14:05:49 I guess you mean, we should clarify all the use cases and how those map to policy.json? 14:05:53 ajo: It was just the subject of the API being Admin only that there were some corner cases that people highlighted 14:06:07 QoS is all about corner cases ':D 14:06:23 it may come up again in review - I think we should proceed with the current plan of admin only but be prepared for people to poke holes in the thinking when it goes under review 14:06:26 seam I think we can start with Admin at the first go 14:06:37 makes sense, 14:06:49 stick to the plan, and address the corner cases with RBAC 14:06:59 and policy.json instructions, for now 14:06:59 and RBAC implementation may land by then 14:07:20 probably RBAC could be our next step to look at 14:07:28 +1 14:07:36 together with DSCP support merging, of course 14:07:36 I'll check the spec and see if we have anything about RBAC, just so I don't forget 14:07:54 sc68cal, there is, but just a very brief reference, may be we'd like to expand that 14:08:26 ajo: ok, that sounds good. I'll check it and if it needs expansion I'll push a patch 14:08:58 anyway, sorry to hijack, please continue :) 14:09:18 I guess, we soon need a) the spec approved so we can start working (I'd suggest myself iterating faster over the spec, and I'd be thankful for fast reviews too, you're doing your part so far... ;) 14:09:27 Do we got to support RABC for liberty? 14:09:29 sc68cal, no no, perfact, sounds good 14:09:37 vikram: probably not 14:09:47 ok 14:09:50 vikram RBAC is under development, we may have some sort of RBAC during liberty 14:09:57 but not yet ready 14:10:03 kevinbenton ^ ;) 14:10:07 lets spec in details only what is going to be immediatly supported 14:10:16 yes that I was thinking that RBAC will itself land in liberty 14:10:23 my plan was mention RBAC in the context of "first iteration will be admin only, then RBAC will be used to give finer grained control" 14:10:32 irenab: there's a future work section for all the ideas we want to put in backlog, so we can prioritize them 14:11:30 ajo: I guess I am now concerned with first iteration :-) 14:11:40 irenab, of course ;) 14:12:37 we may settle down on going in or out of tree, I'm more in favor of in, but out could be also be ok, that would even allow us to initially iterate faster, 14:12:56 btw, irenab , I checked that we have support for db migrations on out-tree advanced services 14:13:21 ^ seems like a good reason to be out of tree 14:13:33 sorry for being late…catching up 14:13:45 being in tree or being in neutro like advanced services? 14:13:51 let's just get the API extension and resources in tree then follow what the *aaS repos are doing 14:14:07 using a service plugin approach is clear to me, let's take that path 14:14:14 sc68cal: +1 14:14:16 +1 14:14:20 +1 14:14:30 +1 14:14:33 sc68cal, you don't need the api extension or resources in tree 14:14:36 afaik 14:14:43 ajo: woo! even better 14:14:50 sc68cal, if we do it out, all in one place 14:14:57 but still, I'm unsure that's the best way to go, 14:15:03 again, even if we build on service plugin 14:15:07 Hello! Sorry I am late today. 14:15:10 I don't see it as an "advanced service" 14:15:24 sc68cal: I think we should keep it together with service plugin, but better be under the ‘big tect’, meaning in openstack and not stakeforge 14:15:33 it's just modifying ports :) 14:15:49 irenab, may be that makes sense 14:15:58 as other *aaS go under the neutron tent 14:16:07 as a service plugin, it'd be within the neutron main repo right? or its own 14:16:22 sc68cal, it can be done one way or another :) 14:16:25 sort of fuzzy on service plugins, it's been a while 14:16:41 sc68cal, check LBaaS repo 14:16:49 very clarifying 14:16:49 1 sec 14:16:52 ajo: ah, my cake and eat it too! ok, then that sounds good to me, I think as long as we have a separate repo to quick iterate that's great 14:17:18 agree 14:17:21 thanks for the protip ajo i'm going to check that out as well 14:17:33 https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas 14:17:43 thx 14:17:59 sc68cal, irenab , vhoward , I'd check with cores btw that the approach seams reasonable, because if they want it back later in time, it could be a mess 14:18:09 I'm more in favor of in, but out should work too, 14:18:15 we may need to dedicate extra resources to set CI, etc... 14:18:34 chose a gating strategy... 14:18:49 make sure those is correctly exposed to all plugin writers.. 14:18:57 db migrations: https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/db 14:19:01 i'd prefer in also, but whatever gets it upstream when it comes down to it 14:19:05 extensions: https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/extensions 14:19:20 I talked to dougwig 14:19:32 and the main point is depending on the low level apis by neutron... 14:19:42 when something changes in the api, you get broken 14:19:49 he suggests having a neutron_lib 14:19:57 the "broken rate" is around 1/week 14:20:07 the reference implementation of dscp we are thinking will be an extention to mechanism driver for ovs to get it upstreamed quickly 14:20:21 who's going to devote resources to keep the out-of-tree implementation healthy? :) 14:20:32 this is my main reason to prefer "in" if that makes sense for neutron, of course ^ 14:21:31 regardless if it in or out, I think it should be service plugin and not mixin into L2 plugin 14:21:40 if we are a few, it could be a rotating position, or a requirement to stay "qos-core" ;D 14:21:49 irenab total agreemen on that 14:22:14 ajo: +1 14:22:17 irenab, after some struggling and trying to understand neutron it's the conclusion I got. 14:23:00 ok 14:23:05 #topic open agenda 14:23:08 IMHO anyways we need to maintain the CI for atleast sometime till it stablizes 14:23:22 I guess we are in open agenda for a while already :D 14:23:34 +1 for service plugin 14:23:35 vikram, not sometime, always :) 14:23:53 I am not sure how QoS in group based policy fits into all of this 14:23:53 ajo: :) 14:23:56 vikram, we may need to maintain co-gating implementation if we keep cogating, or any CI that breaks 14:24:12 sadasu, I talked to the people doing GBP, and they're willing to use our API when ready 14:24:21 sadasu, but that's just higher level abstraction 14:24:31 I talked to ivar lazarro specifically 14:24:38 ajo: Thanks for explaining 14:24:50 #link https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective 14:24:57 some interesting stuff, if you didn't have the chance to see it 14:25:49 the people from HP solved the ingress limiting case with on-compute agents that monitor traffic and send messages to each other throttling egress as necessary 14:25:50 It's good but I feel we don't have to do anything special for GBP. Right? 14:25:56 ajo: thanks! will take a look and see if I still have some remnant questions on GBP and this API tying together 14:26:16 not that excited about maintaining our own gating forever but i can help with setting it up to get this upstreamed if we go that route 14:26:19 sadasu, thanks, that sounds good, I must admit I'm a GBP ignorant 14:26:25 ajo: It's good but I feel we don't have to do anything special for GBP. Right? 14:26:43 vhoward, yes, that's my main concern, thanks , any help will be valuable 14:27:01 vikram, this is what I understand, right 14:27:49 ok 14:28:03 anything you'd like to talk about or shall we endmeeting for today? :) 14:28:05 ok 14:28:20 When we will start the implementation 14:28:27 i'm good 14:28:31 i mean what is the plan? 14:28:37 are there any implications for ML2 ? 14:28:49 vikram, when spec is approved we could start, or... if it's going to be out of tree, we could already start 14:29:10 sadasu, ML2{OVS/LB/SRIOV} is our target plugin 14:29:22 ajo: We got to decide soon as the liberty cycle is small :) 14:29:30 vikram: I totally agree 14:29:49 I will push an updated spec with the last comments, and we may call for it on the next neutron meeting 14:29:54 is it monday or tuesday next week? 14:30:04 we may ask mestery for a slot ^ 14:30:04 I guess we should decide on design, maybe we can spend next meeting to discuss it? 14:30:20 ajo: agreed, they are the reference ML2 plugins we are targeting, but any implication for the ML2 plugin code itself? 14:30:23 ajo: Tuesday next week, so better aligned to European times :) 14:30:38 thanks mestery :) 14:30:49 could you save us a tiny slot ? 14:30:59 ohhh... this will be tough for me :) 14:31:27 sadasu, not sure, may be irenab has more insight on this as she spent some time on that level of the design 14:31:52 irenab, I agree 14:32:01 any conclusion for horizon part? 14:32:16 ajo: I think irenab and vhoward are right, using a ml2 extension driver will make changes to ML2 non-invasive (http://specs.openstack.org/openstack/neutron-specs/specs/juno/neutron-ml2-mechanismdriver-extensions.html) 14:32:16 irenab, may be we should prepare another spec with the messaging layer for the agents using messaging 14:32:22 AFAIK, we need a BP for horizon changes 14:32:49 sc68cal, that part is still blurry to me, more code to read :) 14:33:02 vikram, you're right, we had a volunteer, right? :) 14:33:10 ajo: me too, but that spec linked helps clarify 14:33:11 ajo: We should have support for agentless plugins as well 14:33:14 well i'm figuring it out as well, i think irenab has a much better understanding i'm just hoping to learn some from her 14:33:17 also mrunge offered me support on this regard from horizon 14:33:22 but we need to settle the api first 14:33:28 thats great 14:33:43 API is the only thing blocking everyone from working in parallel 14:33:44 yup.. probably he will there next week.. but if doesn't turn up then we got to start 14:33:49 irenab, of course, how do other *aaS do that? 14:33:55 ajo: I will be taking up the UCSM (agent less) plugin 14:33:59 irenab, they let DB being read and they notify on changes? 14:34:11 sadasu: +1 14:34:13 thanks :) 14:34:18 ajo, sorry? 14:34:32 mrunge talking about QoS API <-> horizon integration, 14:34:49 we have a volunteer to do it (not you), and I was commenting that you offered me support to show me how to do it.. 14:34:56 ajo: other services rely mainly on L3 agent, its a bit different 14:35:19 I can also contribute for neutron-pythonclient and neutron server implementation for db updation 14:35:20 ajo, I did? if yes, I seem to forgot that, but of course! 14:35:28 irenab, ok, we will need to sort that out, 14:35:49 mrunge: private talk near the RDO both, next to larsk (I hope I'm not pinging the wrong mrunge) :D 14:36:20 oops 14:36:23 :D 14:36:37 vikram, true, we need also to handle the neutron-python client, thanks for stepping up ;D 14:37:12 irenab, if you have some time, we can work on next meeting agenda during mon/tues next week 14:37:36 ajo; Let's as you mentioned lets decide next week about work distribution once the spec is approved. 14:37:36 to check all steps we need to figure out the design and what are the pain points we need to talk about 14:37:47 ajo: fine 14:38:20 and we probably should have the advanced service framework to start rolling with the work 14:38:43 I wonder if we have some sort of *aaS template for neutron :) 14:39:21 I have done it earlier, if you need I can do it 14:39:32 I have done for Juno 14:39:33 thanks vikram :) 14:39:57 Ok will prepare before next week meeting and share 14:40:04 awesome vikram :) 14:40:17 #action ajo update spec for API & OVS agent 14:40:33 #action irenab & ajo work on agenda for next week about design 14:41:01 #action vikram prepare an *aaS template for the case we go out tree, or to put in-tree... as we finally decide 14:41:28 #action vhoward work on the DSCP rule spec 14:41:50 vhoward: let me know if you need help on it 14:41:52 and I guess that's all I didn't action-log 14:41:53 ;) 14:42:06 ok, shall we endmeeting ? :) 14:42:13 yes :-) 14:42:16 +1 14:42:19 #endmeeting