14:02:49 <ajo> #startmeeting neutron_qos
14:02:50 <openstack> Meeting started Wed May 13 14:02:49 2015 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:54 <openstack> The meeting name has been set to 'neutron_qos'
14:03:06 <ajo> #topic specs
14:03:21 <ajo> Current shape of the spec: single api URI for rules,
14:03:26 <ajo> #link https://review.openstack.org/#/c/88599/11/specs/liberty/qos-api-extension.rst
14:03:53 <ajo> from the last change to now, I've moved it back to a single URI for rules
14:04:19 <ajo> as the other approach seemed to complicate things
14:04:36 <ajo> I wonder how a single URI end plays with micro versioning, we probably would have a better control over different URI ends
14:05:10 * mestery lurks
14:05:26 <ajo> see line 280
14:05:29 <ajo> hi mestery  :)
14:05:40 * mestery waves at ajo
14:06:03 <ajo> I haven't been able to do my homework and see if we have an easy way to map this to the cmdline client while keeping all rule type arguments in separate helps
14:06:15 <ihrachyshka> ajo, I'm sorry for dumb question, but what is 'multiple URI' alternative?
14:06:19 <ajo> I'll make sure I've investigated it before the summit session
14:06:23 <ajo> ihrachyshka, sure, 1 sec
14:06:27 <ajo> not a dumb question
14:06:49 <ajo> right now, the current state proposes:
14:06:50 <ajo> POST /v2.0/qos-rules
14:06:54 <ajo> while before we had
14:07:07 <ajo> POST /v2.0/qos-bandwidth-limiting-rules/
14:07:08 <ajo> for example
14:07:15 <ajo> qos-<type>-rules/
14:07:16 <ajo> or..
14:07:19 <ajo> we could do
14:07:32 <ajo> v2.0/qos-rules/bandwidth-limiting/
14:07:45 <sc68cal> ^ that sounds more feasible
14:07:53 <ajo> the last one?
14:07:56 <sc68cal> compared to qos-<type>-rules
14:08:00 <ajo> yeah, probably
14:08:03 <ihrachyshka> ah, ok, thanks. maybe the explanation belongs to Alternatives section of the spec. with rationale on why it's wrong. (I vote for aesthetics)
14:08:08 <ajo> this way we will have finer grain control with micro versioning
14:08:31 <ajo> ihrachyshka +1
14:08:32 <ajo> that makes sense
14:08:37 <ajo> let's keep all the options in alternatives
14:08:55 <ajo> any opinions about moving to /qos-rules/<type>/  ?
14:09:09 <ajo> I guess that also matches with the "features" which are drafted over the microversioning API proposal
14:09:12 <vhoward> +1 on v2.0/qos-rules/bandwidth-limiting/
14:09:19 <ajo> were plugins could opt-in to features
14:09:22 <ajo> features could be specific rule types
14:09:36 <ajo> ack
14:09:52 <ihrachyshka> yeah, it should be easier to extend with multiple levels
14:10:06 <ajo> #action ajo change the rules URI to /v2.0/qos-rules/<rule-type> and keep all other options in the Alternatives section
14:10:21 <ajo> ok
14:10:41 <ajo> I posted another spec about the lowest level OVS bits: https://review.openstack.org//#/c/182349/
14:11:07 <ajo> thanks for the comments, if somebody didn't have a chance, please review
14:11:38 <ajo> irenab wasn't able to join today
14:11:55 <ajo> but she wanted to make a note about the datamodel changes we've done with armax suggestions
14:12:13 <ajo> we changed from an open json blob for rule types & parameters
14:12:19 <ajo> into something more tightly coupled to the data model
14:12:30 <ajo> since we need to model each rule type as a table extending QoSRule
14:12:55 <ajo> she's worried about the flexibility of this approach if the development of the "QoS service" is done in a separate tree
14:13:14 <sfinucan> hi - apologies for being late
14:13:25 <ajo> she believes it's a point we may discuss over summit, so I guess we can keep a few minutes for it
14:13:27 <ajo> hi sfinucan !
14:14:22 <ajo> a separate tree implementation, with an strict datamodel, would , currently require patches to the neutron server core to update the datamodel for every new rule type.
14:14:51 <ajo> but I guess that could be addressed in the future if advanced services can bring their own data migrations
14:15:20 <ajo> any thoughts about this? :)
14:15:28 <ihrachyshka> ajo, don't they already?
14:15:39 <ajo> ihrachyshka, I'm unsure, could be
14:15:46 <ihrachyshka> HenryG mentioned some adv-services specific alembic trees in email today in openstack-dev@
14:15:46 <matrohon> ajo : I also though they were
14:16:05 <matrohon> at least they are for vpnaas
14:16:19 <ajo> hmmm thanks ihrachyshka ,  I will check for that email thread, if you can #link paste the link it'd be very handy
14:16:25 <ihrachyshka> ajo, I think it's ok to go with strict version now and see whether people cry too loud
14:16:26 <ajo> matrohon, ihrachyshka  ++ thanks, that's very valuable input
14:16:37 <ihrachyshka> ajo, looking
14:16:38 <ajo> ihrachyshka I'm happier with the stricter datamodel
14:16:56 <ajo> It leads to better user experience, and parameter standarization without bloating the business logic to check all the fields
14:17:00 <ajo> fields=parameters
14:17:02 <matrohon> however I d'ont know if there are still some foreign key between neutron and adv-service
14:17:02 <ihrachyshka> ajo, http://lists.openstack.org/pipermail/openstack-dev/2015-May/064031.html
14:17:05 <ajo> ihrachyshka thanks
14:17:10 <ajo> #link  http://lists.openstack.org/pipermail/openstack-dev/2015-May/064031.html
14:17:49 <ajo> ok, I guess we can move on to the next topic
14:18:06 <ajo> #topic ingress/egress bw limiting
14:18:42 <ajo> Finally with all the gathered info, I believe we should focus on egress as a priority,
14:18:54 <ajo> since ovs is lacking ofmetering support yet
14:19:28 <ajo> and the possible solutions are excessively twisted IMHO, and it's not an important use case (at least when I've discussed it)
14:19:50 <ajo> I mean the possible solutions for ingress bw limiting
14:20:19 <ajo> btw vikram__ I was able to check the ingress rate policy settings in ovs-vsctl, and those are actually VM egress (ingress from the switch POV)
14:20:32 <ddepaoli> what are the solutions for egress rate?
14:20:51 <ajo> ddepaoli, making a mirrored tap interface, and then filtering on that mirrored "tap" egress
14:21:01 <vikram__> ok.. Sorry I could not spend time for it.
14:21:07 <ajo> vikram__, no worries
14:21:35 <ajo> ddepaoli, openflow has support for it, OF1.3 , openflow metering rules, ... but that's not in openvswitch yet
14:22:55 <sfinucan> ajo: the ingress rate limiting built into Nova (via libvirt driver) works like this
14:23:15 <sfinucan> and it doesn't work with SRIOV, for this reason
14:23:21 <ajo> yes, i know libvirt has support for qos, I believe gsagie pointed it out,
14:23:35 <ajo> yes, it's very coupled to nova/qemu
14:24:05 <ajo> IMO we can solve ingress at a later time, and focus in other issues which are probably more important
14:24:28 <sfinucan> agreed
14:24:42 <ajo> sfinucan, thanks for the input :)
14:24:51 <sc68cal> Let's work on the API and framework - so that people can then independently work on their own qos types
14:25:02 <ajo> sc68cal +1
14:25:12 <ihrachyshka> +
14:25:39 <vikram__> +1
14:25:42 <ajo> ok, anybody wants to raise any specific topic before we jump into QoS session planning ?
14:26:18 <vikram__> the qos wiki page is old .. i think we gonna update
14:26:27 <ajo> vikram__, which one?
14:26:29 <vikram__> it's confusing
14:26:37 <vikram__> i sent you the link
14:26:43 <ajo> yes, and probably we should get all the blueprints updated with the new design decissions
14:26:45 <vikram__> let me check
14:26:52 <ajo> sc68cal is the owner of most of them :), I'll need your help sc68cal
14:27:29 <sc68cal> ok
14:27:36 <vikram__> https://wiki.openstack.org/wiki/Neutron/QoS
14:27:43 <vikram__> ok
14:28:07 <sc68cal> what specifically do we need to update?
14:28:27 <vikram__> the content is old i feel
14:28:50 <sc68cal> I think it's low priority at this point
14:29:04 <vikram__> New work link will be better
14:29:09 <ajo> vikram__, I'd move all this to the meeting page if that sounds ok, or we can just link it and keep it updated
14:29:49 <ajo> sc68cal, yes, about the blueprints we will need to do it at a later time, renaming the "quantum-qos" to "neutron-qos" could be a nice thing :D
14:29:55 <vikram__> ok
14:30:19 <ajo> sc68cal, unless you want to show the world how much is this taking, which... could be fair
14:30:19 <ajo> :)
14:30:27 <sc68cal> ajo: read my mind ;)
14:30:27 <vikram__> Just an open item in my mind so pointed:)
14:30:38 <ajo> sc68cal lol, you want to keep it
14:30:56 <sc68cal> similar to the wiki, low priority to me - more interested in getting code complete
14:31:09 <sc68cal> or forging consensus on the code
14:31:23 <ajo> sc68cal, yep, but we need to link blueprints from code... at that point we can go and do a quick blueprint update
14:31:50 <ajo> ok
14:31:58 <ajo> let's plan the summit session!
14:32:11 <ajo> let me first...
14:32:19 <ajo> #link https://wiki.openstack.org/wiki/Neutron/QoS
14:32:27 <ajo> to remember we need to update it
14:32:36 <ajo> #topic QoS summit session planning
14:32:55 <ajo> #link https://etherpad.openstack.org/p/YVR-neutron-qos
14:33:18 <ajo> I come with a totally agenda I'd like to shape together with you
14:33:51 <ajo> I guess, one important point, is presenting the current state of the API
14:34:24 <ajo> to get feedback about how it looks, and how're we going to do it
14:34:35 <vhoward> wonderful, def think that should be included
14:34:49 <ajo> the proposed work scope for this cycle
14:35:01 <ajo> what we plan to do : bw limiting rules, basic admin control, etc...
14:35:19 <ajo> and how could we extend that with RBAC when that's available
14:36:12 <ajo> I'd leave a "looking into the future section" for the end, if we have time
14:37:19 <ajo> also, a point of future needs for integration with nova scheduler (related to guarantees)
14:38:07 <ajo> we haven't yet iterated about how to do the mid levels of the design
14:38:12 <ajo> RPC & plugin integration
14:38:47 <ajo> so far to me a service could make sense (from the design separation POV), even if I don't believe this is an advanced service making use of ports
14:39:12 <ajo> sc68cal, mestery , all, do you believe it's interesting to include a point about this ^
14:39:13 <ihrachyshka> also heat?
14:39:19 <ajo> or we could end up on an endless discussion
14:39:20 <ihrachyshka> sorry... wrong tab
14:39:39 <ajo> ihrachyshka np, It made sense in the scheduling context, lol
14:39:43 <sc68cal> hmm
14:40:18 <ihrachyshka> the wind of change suggests it should be out by default.
14:40:46 <mestery> ajo: It's possible, yes.
14:40:51 <ajo> from summit to the QoS sprint, we have like 1.5months, all those points would need to be agreed before doing the QoS sprint, otherwise we'd probably just burning time
14:41:54 <matrohon> ajo : +1 for adv-service, but it needs a stable callback mechanism
14:41:55 <ajo> mestery, ihrachyshka , sc68cal , we also have the separate/core tree for the service, if we go "aaS"
14:42:12 <matrohon> ajo : or we'll have to implement your own mechanism driver
14:42:19 <ajo> matrohon, sure, the callback mechanism could still be enhanced, but is it unstable?
14:42:24 <mestery> ajo: That's true, it's worth thinking about. I'm keen to hear this discussion out in Vancouver
14:42:52 * mestery is on an A319 which is about to land so he'll drop out soon
14:43:07 <ajo> mestery have a safe landing! ;)
14:43:19 <ajo> I love flights with wifi
14:43:29 <matrohon> ajo : this interface is still new, and kwargs ar put into it, preventing the receiver to know exactly what is inside...
14:43:29 <mestery> ajo: +1000!
14:43:59 <ajo> matrohon, true, not an strong contract for arguments,
14:44:04 <ajo> may be we need callback microversioning ;)
14:44:08 <matrohon> ajo : it needs an interface contract
14:44:13 <matrohon> ajo : +1
14:44:21 <matrohon> :)
14:44:59 <ajo> ok: https://etherpad.openstack.org/p/YVR-neutron-qos
14:45:30 <ajo> any other ideas which are worth discussing?
14:45:57 <ajo> ah, I'm just remembering some feedback irenab  provided about this
14:46:19 <ajo> she wanted us to draft what would be the process of adding new rule types based on the current design
14:46:23 <ajo> 1) add the datamodel (review here or there...)
14:46:39 <ajo> 2) add the API URI handlers fro the rule...
14:47:10 <ajo> 3) add the backend support...
14:47:19 <ajo> and any RPC changes
14:47:31 <ajo> well, for RPC I believe we should make a design that needs no new RPC changes for every new rule type
14:48:30 <ajo> ok :)
14:48:42 <ajo> if there's no more feedback we can close the meeting earlier
14:49:09 <ajo> feel free to comment on the etherpad anytime..
14:49:30 <vikram__> what all driver support we will be eyeing for the first release?
14:50:19 <ajo> vikram__, matrohon , sc68cal , ihrachyshka , sfinucan , matrohon , ddepaoli  , vhoward  , sadasu ,
14:50:21 <ajo> *
14:50:29 <ajo> thanks a lot for joining
14:50:37 <ajo> vikram__, what do you mean ?
14:51:11 <ajo> I signed up for ML2/OVS, and you did for ML2/LB, the minimum is the reference implementation
14:51:24 <vikram__> ok
14:51:50 <ajo> ahh, also matrohon for ML2/SRIOV
14:52:00 <vikram__> just want to confirm on this..
14:52:09 <matrohon> ajo : I didn't :)
14:52:14 <ajo> vikram__ +1
14:52:15 <vikram__> :)
14:52:25 <ajo> not you, sorry... hmmm
14:52:37 <matrohon> moshele probably?
14:52:40 <vikram__> confusions around :)
14:52:42 <ajo> moshele :)
14:52:55 <sc68cal> as long as *an* implementation lands with the other code changes
14:53:01 <ajo> the tab cheated me :)
14:53:09 <sc68cal> the others can be developed at a different pace
14:53:34 <ajo> correct, I'm not sure if we're generally obligated to go with the reference one...
14:54:00 <sc68cal> yes, we are
14:54:19 <ajo> anyway, we both signed up for ovs, so.. that will be there :D
14:54:42 <ajo> ok :)
14:54:50 <ajo> let's "endmeeting"
14:54:53 <vikram__> i will ensure
14:54:54 <ajo> #endmeeting