14:07:30 <ihrachyshka> #startmeeting neutron_qos
14:07:31 <openstack> Meeting started Wed Jul 29 14:07:30 2015 UTC and is due to finish in 60 minutes.  The chair is ihrachyshka. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:07:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:07:35 <openstack> The meeting name has been set to 'neutron_qos'
14:07:37 <jschwarz> hello ihrachyshka
14:07:43 <jlibosva> hello jschwarz
14:07:46 <ihrachyshka> I'm really sorry for delay, we were in the middle of argument with jlibosva  :)
14:07:50 <jschwarz> hello jlibosva ;p
14:07:57 <ihrachyshka> #topic Announcements
14:08:06 <ramanjaneya_> Hi
14:08:30 <ihrachyshka> L2 is this week, and we were supposed to have something the week after it
14:08:50 <ihrachyshka> yesterday we talked with Kyle, and he thinks we should try to go before feature/pecan
14:08:57 <ihrachyshka> I hope we'll make it :)
14:09:15 <ihrachyshka> any other stuff to announce?
14:09:38 <ihrachyshka> ok, I assume no :) moving on
14:09:51 <ihrachyshka> #topic where we stand
14:10:07 <ihrachyshka> we have API tests in gate - yay
14:10:13 <ihrachyshka> we have get_info in the tree - yay
14:10:32 <ihrachyshka> and we have ovs client tweaks from moshele in review: https://review.openstack.org/206525
14:11:03 <ihrachyshka> the missing parts: functional/fullstack tests (I believe jschwarz/ jlibosva were looking into it)
14:11:15 <moshele> ihrachyshka: I upload new patch to resolve the minor comments
14:11:19 <ihrachyshka> 2. ajo's update notifications (he said he will update the patch today)
14:11:33 <jschwarz> I'll might not have enough time to work on the functional, depending on whether I'm working next week or not...
14:11:41 <ihrachyshka> 3. client - I believe jschwarz works with ramanjaneya_ and others to make it happen
14:11:51 <ihrachyshka> jschwarz, ack, we'll control the damage
14:11:53 <jlibosva> I'm looking in functional agent tests
14:11:57 <ihrachyshka> jlibosva, great!
14:12:08 <ihrachyshka> and 4. <- always missing...
14:12:10 <ihrachyshka> devref
14:12:13 <moshele> ihrachyshka: it the neutron client working with rules now ?
14:12:33 <ihrachyshka> please start updating the devref file for qos with more details, we'll need them for review on merge-back
14:12:39 <jschwarz> moshele, I'm working on the neutronclient so hopefully we'll have something soon
14:12:43 <ihrachyshka> jschwarz, ^^ is it?
14:12:58 <ihrachyshka> yeah, jschwarz is quick, I believe we have it covered ;D
14:13:12 <jschwarz> If it will work, it'll work only with the post-#207053
14:13:26 <jschwarz> :)
14:13:34 <ihrachyshka> there are some arguments around API. I believe it should have proper attention: https://review.openstack.org/207053
14:13:56 <jschwarz> arguments?
14:13:56 <ihrachyshka> jschwarz, it may be not easy to convince people to go that route at that point in time, so please share your concerns
14:14:23 <jschwarz> my concerns are that using URIs that are similar to
14:14:40 <jschwarz> /qos/policies/%(policy)s/bandwidth_limit_rules/%s(rule)s
14:14:59 <jschwarz> is a bit pointless, since most of the actions regarding bandwidth_limit_rules don't even need a policy_id
14:15:18 <ihrachyshka> jschwarz, well, you still pass it in body
14:15:21 <jschwarz> so updating a rule, deleting a rule, showing a rule, etc - we can do that using direct DB query that is independent of the policy_id
14:15:37 <jlibosva> what is the benefit of such approach?
14:15:43 <jschwarz> ihrachyshka, yes. for example creating a new rule has to have a policy_id, so we pass it in the body of the request
14:16:11 <ihrachyshka> jschwarz, if we stick to current approach, can we get it from URI instead?
14:16:26 <jlibosva> I propose to have rules as attributes of policies
14:16:26 <jschwarz> jlibosva, the benefit is twofold: having the code easier to manage and having neutronclient code a lot (a lot!) easier to debug and write
14:16:43 <jschwarz> ihrachyshka, how do you mean?
14:17:14 <ihrachyshka> jschwarz, well, you already get policy_id as an argument to qos service plugin endpoints, right?
14:17:24 <jschwarz> yes
14:17:56 <ihrachyshka> I am with code simplicity, but jlibosva has concerns around rules that are in essence policy attributes be independent of it.
14:18:15 <jschwarz> jlibosva, what kind of policy attributes are we talking about?
14:18:16 <ihrachyshka> that said, I agree it reflects what we do for e.g. subnets vs networks and don't mind
14:18:24 <ihrachyshka> jschwarz, rules
14:18:38 <ihrachyshka> jschwarz, each rule type is basically an attr on policy
14:18:43 <jlibosva> or maybe now I'm thinking about design - given that we used to have 'type' per rule, should we have a rules collection per policy?
14:18:48 <jschwarz> oh yikes
14:19:15 <ihrachyshka> jlibosva, I don't think we want to allow rules being written thru create on policies
14:19:17 <jlibosva> jschwarz: well, there is obviously a 1:1 mapping between policy and rule collections
14:19:28 <jschwarz> I think the problem with what Kuba is suggesting is that it doesn't allow a one-to-many mapping between rule to policies (ie. reusing rules)
14:19:38 <jschwarz> lol
14:19:44 <jlibosva> ihrachyshka: I agree on that, policies and rules should be separate objects
14:20:48 <jlibosva> jschwarz: rules are quite small objects carrying just a piece of information. I mean, I don't know what the use case would be about assigning rule to a different policy ...
14:21:17 <ihrachyshka> jschwarz, well, I am not against making it reusable, but ... not in this point in cycle :) I still feel bad I was not on design phase.
14:22:00 <ihrachyshka> jlibosva, well... for policy in policies: apply single rule? (that's assuming we allow reuse)
14:22:10 <ihrachyshka> it may be allowed later
14:22:12 <jschwarz> jlibosva, how about having a lot of networks, all with the same single rule? one might want to change that rule and have it affect all the networks in the tenant
14:22:26 <ihrachyshka> while if we go with current approach, we are locked into subattrs
14:22:38 <jlibosva> jschwarz: networks will have the same policy
14:22:41 <ihrachyshka> jschwarz, it's not in spec, but I agree
14:22:54 <ihrachyshka> jlibosva, well, ok, all policies
14:23:04 <jschwarz> I think that whatever we choose, we must remember to look at the neutronclient before making the decision
14:23:31 <jlibosva> I think neutronclient should adopt server, not vice versa
14:23:39 <jschwarz> neutronclient's code is very restrictive in that it expects paths and objects to be in a specific way and that's a main reason why 207053 was proposed.
14:23:40 <ihrachyshka> jschwarz, you have an obvious benefit here since you actually looked
14:24:04 <jlibosva> ihrachyshka: I don't get all policies - you mean having lots of policies all of them using single rules?
14:24:12 <jschwarz> jlibosva, yes
14:24:13 <ihrachyshka> do we have examples in other services where they embed objects?
14:24:32 <jschwarz> not yet... maybe lbaasv2 does it with members?
14:24:35 <ihrachyshka> jlibosva, yes, they may differ on some other rules but not that one
14:24:38 <jlibosva> well, if there is such use case then it makes sense. I thought that rule will have a single policy-id
14:24:56 <ihrachyshka> jschwarz, I just wonder that if there is something there to steal, why can't we do it?
14:25:10 <jschwarz> ihrachyshka, who said we're not stealing? :)
14:25:11 <ihrachyshka> jlibosva, atm it won't, but I think it's a reasonable move to allow it
14:25:14 <jlibosva> jschwarz: lbaas does it with health-monitors
14:25:37 <jlibosva> ihrachyshka: then we should make the decision on what is expected
14:25:41 <jschwarz> I looked for a bit and didn't see one case of a URI such as /qos/policies/%s/bw_limit_rules/%s
14:25:59 <jschwarz> lb members for example looks like /lb/members
14:26:03 <ihrachyshka> jschwarz, have you looked at health-monitors?
14:26:03 <jlibosva> if there will be mapping 1:N between policies and rules, makes sense. If 1:1, we should make it easier
14:26:19 <jschwarz> likewise lb healthmonitors looks like /lb/healthmonitors
14:26:58 <jschwarz> #link https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L383
14:26:59 <ihrachyshka> jlibosva, ^^ ?
14:27:03 <ramanjaneya_> Rule and policy should be 1:1 mapping makes scene
14:27:09 <jschwarz> also: https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L371
14:27:34 <ddepaoli> there's no qos branch for client?
14:27:42 <ihrachyshka> ddepaoli, no, there is no branch for client
14:27:42 <jschwarz> ddepaoli, no, only 2 patches
14:27:44 <jlibosva> ihrachyshka: jschwarz https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L385
14:27:53 <jschwarz> jlibosva, yes, I just saw that...
14:28:14 <ihrachyshka> it's to assoc monitors. is it the same as we need?
14:28:18 <jschwarz> either way it's one URI out of every other URIs
14:28:24 <jlibosva> I wasn't present on design phase so I don't know :) But we must be clear on the relation between rules and policies
14:28:26 <ihrachyshka> we currently talk about CRUD for rules, right?
14:28:48 <jschwarz> ihrachyshka, not only - based on that address we need to be able to also list, show, create, delete...
14:28:50 <ihrachyshka> in design phase, it was told 1:N is YAGNI
14:29:04 <ihrachyshka> I don't think everyone understood it will complicate things
14:29:43 <ihrachyshka> jschwarz, I mean, in that health-monitor example, the URI is used to attach monitors, not create them. for create, they have a root level obj.
14:29:47 <ihrachyshka> the way you suggest
14:30:01 <jschwarz> yes
14:30:02 <ihrachyshka> (unless I misunderstand the var names)
14:30:15 <jschwarz> that makes sense
14:30:25 <jlibosva> but that's because of 1:N mapping, right?
14:30:38 <ihrachyshka> no idea :)
14:31:02 <jschwarz> ihrachyshka, jlibosva, either way you;ll see that in v2 they diverted from that
14:31:05 <ihrachyshka> there is also that one: https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L424
14:31:07 <ihrachyshka> weird one
14:31:11 <jschwarz> meaning they also decided it's a bad idea :)
14:31:40 <jlibosva> jschwarz: link? :)
14:31:47 <ihrachyshka> https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L365 ?
14:31:51 <jschwarz> jlibosva, https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L372
14:32:27 <jschwarz> oh, I now see that on line 374 they do have that heirarchy for /lbaas/pools/%s/members/%s
14:32:58 <jlibosva> well, that's a common thing in rest apis if you have multiple mappings
14:33:02 <jlibosva> I mean 1:N
14:33:56 <jschwarz> that whole 1:N isn't even written yet
14:34:00 <ihrachyshka> jschwarz, how about we spend some time trying to mimic that? api change is not cheap
14:34:20 <jschwarz> sure, i'll see about mimicing that
14:34:33 <jlibosva> what's 'mimicing'?
14:34:46 <jschwarz> jlibosva, fancy word for 'copy pasting'
14:34:47 <jschwarz> XD
14:34:48 <ihrachyshka> jschwarz, ok, thanks a lot. we'll have an option to fall back to your proposal if it does not fly. but we should try to avoid it.
14:34:50 <jlibosva> ok :)
14:35:09 <jlibosva> that was for john's explanation on mimic^^
14:35:19 <jschwarz> XD
14:35:24 <jlibosva> I would try to search for some design practices for rest api
14:35:29 <jlibosva> this seems like a common thing :-/
14:35:39 <ihrachyshka> we also have a patch for sriov, thanks to moshele https://review.openstack.org/206038
14:35:43 <ihrachyshka> please review guys
14:36:11 <ihrachyshka> one more thing... I don't see Gal here. moshele do you by chance know whether someone works on non-native ovsdb qos interface?
14:36:30 <moshele> no
14:36:44 <ihrachyshka> we desperately need this one, since vsctl is the default
14:37:19 <jreeves> I believe we can add it to our roadmap
14:37:32 <ihrachyshka> jreeves, it should be before merge-back I suppose
14:37:34 <jreeves> (we as in vhoward's team)
14:37:36 <ihrachyshka> so we are tight
14:37:51 <ihrachyshka> jreeves, do you think it's realistic?
14:38:16 <jreeves> not sure at this point. I'll have to check with the others
14:38:26 <jreeves> Vic is out today though
14:38:27 <ihrachyshka> jreeves, thanks. please keep my in the loop.
14:38:47 <jreeves> ok
14:38:51 <ihrachyshka> one more thing: I've cleaned up etherpad from some old/implemented stuff
14:38:52 <ihrachyshka> #link https://etherpad.openstack.org/p/qos-sync
14:39:03 <ihrachyshka> please make sure you maintain it in good shape :)
14:39:43 <ihrachyshka> jreeves, we also may need linuxbridge at least for API tests purposes. or we may change rule_types algorithm for ml2
14:40:11 <ihrachyshka> ok, anything more from you guys?
14:40:24 <jreeves> I'll include that request too then
14:40:32 <ihrachyshka> jreeves++
14:40:37 <jreeves> but I don't think we'll be that ambitious lol
14:40:41 <ihrachyshka> heh
14:40:49 <ihrachyshka> well, we have a fallback plan for lb
14:41:16 <ihrachyshka> ah forgot to mention, ajo will be back on Mon :)
14:41:33 <ihrachyshka> ok, I guess we may use remaining 20 mins for code, reviews and what not
14:41:45 <ihrachyshka> #endmeeting