14:01:17 <ajo> #startmeeting neutron_qos
14:01:18 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:20 <vikram> hi
14:01:23 <openstack> The meeting name has been set to 'neutron_qos'
14:01:49 <ajo> #topic summit session
14:01:53 <ajo> #link https://etherpad.openstack.org/p/YVR-neutron-qos
14:02:01 <ajo> just a link for anybody who where not able to attend
14:02:16 <ajo> it was very nice to meet you all (most of you) :)
14:02:41 <sc68cal> likewise :)
14:02:47 <vikram> samehere :)
14:03:01 <ajo> thanks :)
14:03:16 <ajo> 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 <ajo> 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 <ajo> 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 <ajo> so, when we get the first part done, we can look into merging DSCP as fast as possible
14:04:58 <sc68cal> 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 <ajo> sc68cal, can you elaborate? :)
14:05:49 <ajo> I guess you mean, we should clarify all the use cases and how those map to policy.json?
14:05:53 <sc68cal> ajo: It was just the subject of the API being Admin only that there were some corner cases that people highlighted
14:06:07 <ajo> QoS is all about corner cases ':D
14:06:23 <sc68cal> 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 <vikram> seam I think we can start with Admin at the first go
14:06:37 <ajo> makes sense,
14:06:49 <ajo> stick to the plan, and address the corner cases with RBAC
14:06:59 <ajo> and policy.json instructions, for now
14:06:59 <irenab> and RBAC implementation may land by then
14:07:20 <ajo> probably RBAC could be our next step to look at
14:07:28 <vikram> +1
14:07:36 <ajo> together with DSCP support merging, of course
14:07:36 <sc68cal> I'll check the spec and see if we have anything about RBAC, just so I don't forget
14:07:54 <ajo> sc68cal, there is, but just a very brief reference, may be we'd like to expand that
14:08:26 <sc68cal> ajo: ok, that sounds good. I'll check it and if it needs expansion I'll push a patch
14:08:58 <sc68cal> anyway, sorry to hijack, please continue :)
14:09:18 <ajo> 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 <vikram> Do we got to support RABC for liberty?
14:09:29 <ajo> sc68cal, no no, perfact, sounds good
14:09:37 <sc68cal> vikram: probably not
14:09:47 <vikram> ok
14:09:50 <ajo> vikram RBAC is under development, we may have some sort of RBAC during liberty
14:09:57 <ajo> but not yet ready
14:10:03 <ajo> kevinbenton ^ ;)
14:10:07 <irenab> lets spec in details only what is going to be immediatly supported
14:10:16 <vikram> yes that I was thinking that RBAC will itself land in liberty
14:10:23 <sc68cal> 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 <ajo> 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 <irenab> ajo: I guess I am now concerned with first iteration :-)
14:11:40 <ajo> irenab, of course ;)
14:12:37 <ajo> 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 <ajo> btw, irenab , I checked that we have support for db migrations on out-tree advanced services
14:13:21 <sc68cal> ^ seems like a good reason to be out of tree
14:13:33 <vhoward> sorry for being late…catching up
14:13:45 <irenab> being in tree or being in neutro like advanced services?
14:13:51 <sc68cal> let's just get the API extension and resources in tree then follow what the *aaS repos are doing
14:14:07 <ajo> using a service plugin approach is clear to me, let's take that path
14:14:14 <vikram> sc68cal: +1
14:14:16 <moshele> +1
14:14:20 <vhoward> +1
14:14:30 <cbits> +1
14:14:33 <ajo> sc68cal, you don't need the api extension or resources in tree
14:14:36 <ajo> afaik
14:14:43 <sc68cal> ajo: woo! even better
14:14:50 <ajo> sc68cal, if we do it out, all in one place
14:14:57 <ajo> but still, I'm unsure that's the best way to go,
14:15:03 <ajo> again, even if we build on service plugin
14:15:07 <sadasu> Hello! Sorry I am late today.
14:15:10 <ajo> I don't see it as an "advanced service"
14:15:24 <irenab> 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 <ajo> it's just modifying ports :)
14:15:49 <ajo> irenab, may be that makes sense
14:15:58 <ajo> as other *aaS go under the neutron tent
14:16:07 <sc68cal> as a service plugin, it'd be within the neutron main repo right? or its own
14:16:22 <ajo> sc68cal, it can be done one way or another :)
14:16:25 <sc68cal> sort of fuzzy on service plugins, it's been a while
14:16:41 <ajo> sc68cal, check LBaaS repo
14:16:49 <ajo> very clarifying
14:16:49 <ajo> 1 sec
14:16:52 <sc68cal> 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 <irenab> agree
14:17:21 <vhoward> thanks for the protip ajo i'm going to check that out as well
14:17:33 <ajo> https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas
14:17:43 <vhoward> thx
14:17:59 <ajo> 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 <ajo> I'm more in favor of in, but out should work too,
14:18:15 <ajo> we may need to dedicate extra resources to set CI, etc...
14:18:34 <ajo> chose a gating strategy...
14:18:49 <ajo> make sure those is correctly exposed to all plugin writers..
14:18:57 <ajo> db migrations: https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/db
14:19:01 <vhoward> i'd prefer in also, but whatever gets it upstream when it comes down to it
14:19:05 <ajo> extensions: https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/extensions
14:19:20 <ajo> I talked to dougwig
14:19:32 <ajo> and the main point is depending on the low level apis by neutron...
14:19:42 <ajo> when something changes in the api, you get broken
14:19:49 <ajo> he suggests having a neutron_lib
14:19:57 <ajo> the "broken rate" is around 1/week
14:20:07 <vhoward> 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 <ajo> who's going to devote resources to keep the out-of-tree implementation healthy? :)
14:20:32 <ajo> this is my main reason to prefer "in" if that makes sense for neutron, of course  ^
14:21:31 <irenab> regardless if it in or out, I think it should be service plugin and not mixin into L2 plugin
14:21:40 <ajo> if we are a few, it could be a rotating position, or a requirement to stay "qos-core" ;D
14:21:49 <ajo> irenab total agreemen on that
14:22:14 <vikram> ajo: +1
14:22:17 <ajo> irenab, after some struggling and trying to understand neutron it's the conclusion I got.
14:23:00 <ajo> ok
14:23:05 <ajo> #topic open agenda
14:23:08 <vikram> IMHO anyways we need to maintain the CI for atleast sometime till it stablizes
14:23:22 <ajo> I guess we are in open agenda for a while already :D
14:23:34 <sadasu> +1 for service plugin
14:23:35 <ajo> vikram, not sometime, always :)
14:23:53 <sadasu> I am not sure how QoS in group based policy fits into all of this
14:23:53 <vikram> ajo: :)
14:23:56 <ajo> vikram, we may need to maintain co-gating implementation if we keep cogating, or any CI that breaks
14:24:12 <ajo> sadasu, I talked to the people doing GBP, and they're willing to use our API when ready
14:24:21 <ajo> sadasu, but that's just higher level abstraction
14:24:31 <ajo> I talked to ivar lazarro specifically
14:24:38 <vikram> ajo: Thanks for explaining
14:24:50 <ajo> #link https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective
14:24:57 <ajo> some interesting stuff, if you didn't have the chance to see it
14:25:49 <ajo> 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 <vikram> It's good but I feel we don't have to do anything special for GBP. Right?
14:25:56 <sadasu> 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 <vhoward> 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 <ajo> sadasu, thanks, that sounds good, I must admit I'm a GBP ignorant
14:26:25 <vikram> ajo: It's good but I feel we don't have to do anything special for GBP. Right?
14:26:43 <ajo> vhoward, yes, that's my main concern, thanks , any help will be valuable
14:27:01 <ajo> vikram, this is what I understand, right
14:27:49 <ajo> ok
14:28:03 <ajo> anything you'd like to talk about or shall we endmeeting for today? :)
14:28:05 <vikram> ok
14:28:20 <vikram> When we will start the implementation
14:28:27 <sc68cal> i'm good
14:28:31 <vikram> i mean what is the plan?
14:28:37 <sadasu> are there any implications for ML2 ?
14:28:49 <ajo> 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 <ajo> sadasu, ML2{OVS/LB/SRIOV} is our target plugin
14:29:22 <vikram> ajo: We got to decide soon as the liberty cycle is small :)
14:29:30 <ajo> vikram: I totally agree
14:29:49 <ajo> I will push an updated spec with the last comments, and we may call for it on the next neutron meeting
14:29:54 <ajo> is it monday or tuesday next week?
14:30:04 <ajo> we may ask mestery for a slot ^
14:30:04 <irenab> I guess we should decide on design, maybe we can spend next meeting to discuss it?
14:30:20 <sadasu> ajo: agreed, they are the reference ML2 plugins we are targeting, but any implication for the ML2 plugin code itself?
14:30:23 <mestery> ajo: Tuesday next week, so better aligned to European times :)
14:30:38 <ajo> thanks mestery  :)
14:30:49 <ajo> could you save us a tiny slot ?
14:30:59 <vikram> ohhh... this will be tough for me :)
14:31:27 <ajo> 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 <ajo> irenab, I agree
14:32:01 <vikram> any conclusion for horizon part?
14:32:16 <sc68cal> 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 <ajo> irenab, may be we should prepare another spec with the messaging layer for the agents using messaging
14:32:22 <vikram> AFAIK, we need a BP for horizon changes
14:32:49 <ajo> sc68cal, that part is still blurry to me, more code to read :)
14:33:02 <ajo> vikram, you're right, we had a volunteer, right? :)
14:33:10 <sc68cal> ajo: me too, but that spec linked helps clarify
14:33:11 <irenab> ajo: We should have support for agentless plugins as well
14:33:14 <vhoward> 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 <ajo> also mrunge  offered me support on this regard from horizon
14:33:22 <ajo> but we need to settle the api first
14:33:28 <vhoward> thats great
14:33:43 <sc68cal> API is the only thing blocking everyone from working in parallel
14:33:44 <vikram> yup.. probably he will there next week.. but if doesn't turn up then we got to start
14:33:49 <ajo> irenab, of course, how do other *aaS do that?
14:33:55 <sadasu> ajo: I will be taking up the UCSM (agent less) plugin
14:33:59 <ajo> irenab, they let DB being read and they notify on changes?
14:34:11 <ajo> sadasu: +1
14:34:13 <ajo> thanks :)
14:34:18 <mrunge> ajo, sorry?
14:34:32 <ajo> mrunge talking about QoS API <-> horizon integration,
14:34:49 <ajo> 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 <irenab> ajo: other services rely mainly on L3 agent, its a bit different
14:35:19 <vikram> I can also contribute for neutron-pythonclient and neutron server implementation for db updation
14:35:20 <mrunge> ajo, I did? if yes, I seem to forgot that, but of course!
14:35:28 <ajo> irenab, ok, we will need to sort that out,
14:35:49 <ajo> mrunge: private talk near the RDO both, next to larsk (I hope I'm not pinging the wrong mrunge) :D
14:36:20 <mrunge> oops
14:36:23 <mrunge> :D
14:36:37 <ajo> vikram, true, we need also to handle the neutron-python client, thanks for stepping up ;D
14:37:12 <ajo> irenab, if you have some time, we can work on next meeting agenda during mon/tues next week
14:37:36 <vikram> ajo; Let's as you mentioned lets decide next week about work distribution once the spec is approved.
14:37:36 <ajo> 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 <irenab> ajo: fine
14:38:20 <vikram> and we probably should have the advanced service framework to start rolling with the work
14:38:43 <ajo> I wonder if we have some sort of *aaS template for neutron :)
14:39:21 <vikram> I have done it earlier, if you need I can do it
14:39:32 <vikram> I have done for Juno
14:39:33 <ajo> thanks vikram  :)
14:39:57 <vikram> Ok will prepare before next week meeting and share
14:40:04 <ajo> awesome vikram  :)
14:40:17 <ajo> #action ajo update spec for API & OVS agent
14:40:33 <ajo> #action irenab & ajo work on agenda for next week about design
14:41:01 <ajo> #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 <ajo> #action vhoward work on the DSCP rule spec
14:41:50 <sc68cal> vhoward: let me know if you need help on it
14:41:52 <ajo> and I guess that's all I didn't action-log
14:41:53 <ajo> ;)
14:42:06 <ajo> ok, shall we endmeeting ? :)
14:42:13 <irenab> yes :-)
14:42:16 <sc68cal> +1
14:42:19 <ajo> #endmeeting