14:01:25 <ajo> #startmeeting neutron_qos 14:01:26 <openstack> Meeting started Wed May 6 14:01:25 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:29 <openstack> The meeting name has been set to 'neutron_qos' 14:01:43 <ajo> #link https://wiki.openstack.org/wiki/Meetings/QoS#2015-05-06_14:00_UTC 14:02:01 <ajo> #topic API microversioning spec implications 14:02:01 <ajo> #link https://review.openstack.org/#/c/136760/ 14:02:04 <moshele> hi 14:02:11 <ajo> I have included this first point after talking to sc68cal today :) 14:02:23 <ajo> I recommend reading it if you have time, 14:02:34 <irenab> hi 14:02:40 <vikram__> it's too long:) 14:02:51 <vikram__> i tried but couldn't complete 14:03:03 <ajo> this should give us more flexibility about how we model the API & evolve it, but it probably won't be available until mid L (I'm supposing here) 14:03:18 <ajo> vikram__ :D yeah, it needs a good coffee to read it 14:03:22 <ajo> sc68cal, any comments? :) 14:03:44 <vhoward> will take a look thanks 14:04:56 <ajo> ok, let's move on 14:05:13 <ajo> #topic Changes to the QoS API spec: scoping into bandwidth limiting 14:05:34 <ajo> #link https://review.openstack.org/#/c/88599/9..10/specs/liberty/qos-api-extension.rst 14:05:57 <ajo> I iterated a couple of times on the spec since last week 14:06:17 <ajo> armax, from the drivers team had some time to review and provide feedback 14:06:44 <ajo> he asked for some changes in the data model (I'll get to that later) 14:07:13 <ajo> and he asked to scope the initial work into bandwidth limiting 14:08:14 <sc68cal> ajo: sorry, just got scrollback - nothing to add 14:08:37 <ajo> I know sc68cal has comments about my spec title change, but we can find something in the middle, as I keep repearing: I believe it's better if we prepare the data model and the API to be more close to the final desired state that... if we keep changing it and jumping unnecesarily. 14:08:52 <vhoward> yeah saw that, we would love for the data model and api to be flexible enough for our use-cases for marking our network traffic i'll put some notes to help in the spec? 14:09:36 <ajo> vhoward +1 14:09:46 <vhoward> cool, i can put some notes in for us 14:09:56 <vhoward> and help out as you need, just let me know 14:10:14 <ajo> Check the comments about traffic classification & ideas, 14:10:29 <vhoward> cool ajo, thanks for the tip will read up today 14:10:32 <ajo> I believe it will be better modeled like that (I have a point later in the meeting for it) 14:10:51 <ajo> #topic Changes to the QoS API spec: modeling of rules (class hierarchy) (Guarantee split out) 14:11:29 <ajo> ok, if you see , I've modified the current data model, per armax suggestion, to make it more specific 14:11:43 <ajo> I keep the QoSPolicy, composed of QoSRules 14:12:03 <ajo> but now every rule type may have a QoS<type>Rule 14:12:15 <ajo> extending the basic rule information with the specific parameters 14:12:43 <ajo> Also, there was a discussion about splitting rules into smaller combinable chunks, 14:13:04 <ajo> like, guarantees... since there could be plugins not able to provide guarantees, while others would. 14:13:52 <ajo> The idea is plugins can implement rule types as a whole, and separate optional aspects into separate rules (they finally combine in a policy) 14:15:19 <ajo> if you see issues with the current changes, speak now, or... otherwise speak into the spec :) 14:15:24 <irenab> ajo: comparing to specify ‘guarantee level’ atribute in the rule itslef? 14:15:43 <ajo> irenab, what do you mean? 14:15:56 <vikram__> I feel the QoSRule is carrying more information now. How about splitting it out. 14:16:16 <irenab> ajo: what you mentiond before .. like, guarantees 14:16:19 <ajo> vikram__, see comments, Traffic Classification fields are going to be splitted out. 14:16:27 <ajo> but for later iterations, not now 14:16:43 <ajo> just wanted to see how it looked, and the drawbacks of what I had in mind 14:16:49 <ajo> irenab, ahh 14:16:55 <vikram__> ok.. i feel it's just a suggestion from your end and you need more voting before doing:) 14:17:13 <ajo> for example, the previous ratecontrol: max_kbps=10000 min_kbps=3000 14:17:13 <ajo> could be expressed as 14:17:29 <ajo> bandwidthlimit max_kbps=10000 + another rule for guarantee min_kbps=3000 14:17:43 <ajo> guarantee could have a field to say if it's strict, or best effort 14:18:00 <ajo> or we could have a separate rule for besteffort/strict 14:18:23 <ajo> vikram__ +1 :D 14:18:55 <ajo> irenab, this way, if the plugin doesn't opt in tu support the "guarantee" rules... you can't just push that rule 14:19:14 <vikram__> +1 for separate rules. Because it could be vendor specific. 14:19:22 <sfinucan> +1 - very granular 14:19:26 <gsagie> ajo: i think that what ever model which will be easy to extend with extensions which dont effect other plugins just those that implement them is good, 14:20:05 <gsagie> so seperating the rules sounds good as long as the user can understand what is supported and what is not, or do you mean the add will just fail? 14:20:11 <gsagie> in case something is not supported 14:20:16 <irenab> gsagie: +1 14:20:27 <ajo> gsagie, yes, that's one of the things, it fits well in the extension world, but... we'll have microversioning 14:20:29 <ajo> yes, 14:20:52 <ajo> gsagie, there's a point about checking incompatible rules 14:21:15 <ajo> we will need a mechanism to check rules as they are added to see if they can be implemented with the other rules already in the policy 14:21:44 <ajo> for example, you can't ask for a guarantee (min_kbps) > bandwidthlimit (max_kbps) 14:23:22 <ajo> around this (successive extensions), we had another point in the agenda 14:23:34 <ajo> #topic Discuss multiple API end points (per rule type) vs single. 14:23:58 <ajo> with this model, if we had an API end point per rule type (this is being discussed in comments of the spec right now) 14:24:02 <ajo> we could just add one extension per rule 14:24:06 <ajo> (rule type) 14:24:28 <ajo> hmmm, sorry, I'm mixing things up :) 14:24:32 <ajo> that makes a nonsense :) 14:24:44 <ajo> we just extend the port & net once with the QoSPolicy, right? :) 14:24:53 <ajo> (-1 on me, please :) ) 14:25:02 <vhoward> ;) 14:25:30 <irenab> ajo: I guess you mean extending the QoS extension with more qos rule types 14:25:44 <ajo> yes, more about extending the API 14:26:00 <ajo> there are two options here, we can have one api end to create rules 14:26:11 <ajo> or we can have an api endpoint per rule type 14:26:22 <gsagie> ajo : the problem in the world of decomposition is that one might not know of other extensions and it will be hard to maintain (especially with what you said above about checking rules) 14:26:34 <gsagie> so i think in a centralized place, if i understood what you mean :) 14:26:53 <ajo> I'm talking about... 14:27:13 * ajo scrolls on the spec 14:27:43 <ajo> about having: 14:27:55 <ajo> POST /v2.0/qos-<type>-rules 14:27:57 <ajo> one per type 14:27:57 <ajo> or... 14:28:05 <ajo> just a /v2.0/qos-rules 14:28:06 <irenab> ajo: by api end point, you mean REST resource /qos/XXX or different path? 14:28:15 <ajo> where we post & get , UPDATE,e tc 14:28:43 <ajo> irenab correct, API endpoint is another port listening for requests, right? 14:29:10 <irenab> ajo: this is my understanding 14:29:20 <ajo> ok :) 14:29:43 <ajo> so, I mean different rest resources, vs single for types of rules... 14:30:11 <ajo> I have no strong preference for one of another, 14:30:24 <vikram__> To me having one is better.. it can help to minimize the coding effort 14:30:35 <ajo> it was my understanding that having separate ones was preferable from armax POV 14:30:49 <ajo> I guess having one, requires a big "switch" at the api endpoint, to create one rule or another 14:30:50 <irenab> ajo: I think we should go with option that allows easier extension for new type 14:30:51 <ajo> and validate 14:30:53 <gsagie> but you will have single one, you need some code that parse and knows which attribute belongs to which type 14:31:03 <ajo> api endpoint I said again.. 14:31:04 <gsagie> if you 14:31:06 <ajo> ajo-- 14:31:07 <ajo> :) 14:31:07 <vhoward> +1 arenab 14:31:33 <ajo> gsagie, yes, I guess that's it 14:31:56 <vikram__> gsagie: but we can reuse most of it. 14:32:24 <ajo> vikram__, client coding doesn't need to be more complicated it's just a string in the middle of the URL qos-%(type)s-rules 14:32:43 <ajo> also, from the cmdline interface, 14:32:58 <ajo> going one way or another could mean we have separate commands, or just one 14:33:16 <ajo> I believe having just one could be messy because we may end up with a lot of optional commands which only apply to certain rules 14:33:45 <ajo> unless the argparser we use is capable of having another level of optional flags 14:33:45 <vikram__> ajo: Thanks for the explanation... I got it .. having 1 cmd is better to manage i feel 14:34:00 <gsagie> or maybe just /v2.0/qos-rules/<extension or type>/.... 14:34:02 <vikram__> ok 14:34:23 <ajo> gsagie, could be, yes... 14:34:37 <ajo> I wonder if we have this kind of class inheritance somewhere in the project 14:34:43 <ajo> and any API which does the dame 14:34:45 <ajo> dame->same 14:34:59 <ajo> across openstack 14:35:54 <ajo> ok, we need to iron this parts out 14:36:25 <ajo> I will look at the argument parser we use in the client, to figure out if we can put everything under a single command, while still having a clear help 14:36:35 <ajo> about what arguments apply to each rule type 14:37:32 <ajo> and for the REST part, let's keep discussing on the spec. 14:37:40 <gsagie> k 14:37:45 <irenab> ajo: +1 14:38:02 <vikram__> ok 14:38:11 <ajo> #action ajo check if argument parser in the client can handle all rules in one set of commands while still providing granular control of which flags apply to each type 14:38:29 <ajo> #undo 14:38:30 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x927bb90> 14:38:43 <ajo> #action ajo check if argument parser in the client can handle all rule types in one set of commands while still providing granular control of which flags apply to each type 14:38:48 <ajo> rules -> rule types 14:39:21 <ajo> #topic Traffic Classification considerations 14:39:44 <ajo> I believe most of you already read that part of the comments, 14:40:19 <ajo> I was proposing to (when we do TC) create another data model to do traffic classification 14:40:24 <ajo> so that it can be attached to rules 14:40:29 <irenab> ajo: +1 14:40:49 <ajo> this way we don't need to repeat the same filters for rules targetting the same type of traffic 14:41:01 <vikram__> ajo: +1 14:41:14 <irenab> once we get there, need to be careful when this object can be modified 14:41:37 <irenab> not to create too many update dependencies 14:41:39 <gsagie> yes, good point 14:41:43 <ajo> yes, as it will affect several rules 14:42:06 <ajo> at that time we may need to analyze what's better 14:42:17 <ajo> we either let them reattach each rule to a new TC 14:42:18 <ajo> or... 14:42:20 <ajo> modify the TC 14:42:30 <ajo> but that means lots of rules could be updated at the same time 14:42:44 <ajo> from the user usability perspective it's probably simpler to let them change a TC 14:43:13 <ajo> messaging could be short 14:43:51 <irenab> the impact can be high 14:44:24 <ajo> yes it needs to be seriously considered 14:44:32 <irenab> but we can decide later what approach to take 14:44:36 <ajo> yes 14:44:44 <ajo> in an ovs / openflow world 14:44:54 <ajo> we could make use of conjunctive rules 14:45:06 <vikram__> A TC change impacting lot of rules.... Can this be a real use case ? I am not sure.. Is it a practical scenarion? 14:45:22 <ajo> and just modify the rules in the conjunction... that is mapped to the TC 14:45:44 <ajo> vikram__, probably it could only happen if an administrator needs to correct a TC which was wrong 14:45:47 <ajo> or make it more specific 14:45:54 <ajo> probably it's not going to ve a common use case 14:46:02 <ajo> or... 14:46:11 <ajo> or a CSP 14:46:17 <vikram__> ok.. but that could not be frequent.. 14:46:26 <ajo> sorry... nothing about CSPs :) 14:46:33 <ajo> but.. we also have the same case with policies 14:46:45 <ajo> if a CSP has a policy for his cloud 14:46:48 <ajo> and it's changed, 14:46:58 <ajo> (for example BW limit to 10mbps to certain level) 14:47:03 <ajo> it may need to propagate to a lot of ports 14:47:29 <ajo> But , the admin could also create a new policy, and reattach the networks 14:47:33 <ajo> one by one 14:47:59 <vikram__> ok 14:48:29 <ajo> ok, we have another point about "The ingress vs egress differences and issues." 14:49:34 <ajo> probably it's just a matter of documenting the scalability implications of modifiying a policy (or TC), or creating and switching... 14:49:50 <ajo> API documentation I mean 14:50:22 <ajo> I get you all bored :D 14:50:28 <ajo> ok 14:50:34 <ajo> #topic The ingress vs egress differences and issues 14:50:52 <sadasu> ajo: we are listening :-) 14:51:05 <vikram__> i am with you till now:) 14:51:09 <irenab> ajo: you are just very verbose 14:51:13 <ajo> garyk was making an interesting point in last meeting, about including an ingress/egress field 14:51:22 <ajo> irenab: that's true :D 14:51:36 <ajo> I can be either very shy, or very chatty... ;) 14:52:17 <sadasu> I think the idea of including a direction field is a good one 14:52:17 <ajo> I was looking at the implications of supporting egress & ingress control from the linux perspective 14:52:53 <ajo> linux (in netfilter) has only direct support for egress control 14:53:29 <ajo> egress is simpler because you can just tell the packet pushing VM or instance... "I can't take anything more", and the app get's blocked on send... 14:53:42 <sfinucan> ajo: Open vSwitch is the same 14:53:53 <sadasu> I would expect the egress direction to be more useful than ingress 14:54:04 <ajo> gsagie had some ideas bout ingress (metering), but we haven't been able to check yet 14:54:17 <sfinucan> there's basic ingress metering, but that's it 14:54:30 <ajo> sfinucan, but we're not sure if we can make it drop packets or not above some rate 14:54:43 <vikram__> is it documented somewhere? 14:55:03 <ajo> OF1.3 metering, gsagie do you have the link somewhere? 14:55:18 <sfinucan> It is somewhere...but I don't recall where :) 14:55:33 <sfinucan> I was testing it ~3 weeks ago. It dropped packets 14:55:34 <vikram__> hehehe-:) 14:55:34 <ajo> there are ways to do ingress (if we couldn't use metering for this), but they are twisted 14:55:42 <sfinucan> but it was a very rough estimate 14:56:03 <ajo> generally, involves creating a secondary tap/interface, where you send all the ingress traffic which should go to the instance, and then... you filter it's egress 14:56:11 <sfinucan> this should get you something useful -> "sudo ovs-vsctl set interface $IF_NAME ingress_policing_rate=1000" 14:56:12 <ajo> you bounce it back, and finter egress 14:56:15 <ajo> filter 14:56:20 <sfinucan> ajo: sounds about right, yes 14:56:38 <vikram__> thanks ajo will check it 14:56:43 <sadasu> ajo: +1 14:56:43 <ajo> sfinucan, ok, we may check that, 14:56:51 <ajo> vikram__, if have time to check sfinucan : perfect 14:57:08 <sfinucan> ls 14:57:13 <ajo> "test what sfinucan said" I mean, sorry 14:57:14 <vikram__> ok will do that.. 14:57:32 <ajo> https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_traffic_shapping.sh 14:57:35 <ajo> this could help you testing 14:57:51 <ajo> https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_traffic_shapping.sh#L124 14:57:52 <ajo> hmm 14:57:58 <ajo> it's actually what I did 14:58:11 <ajo> but it was limiting egress? 14:58:20 <ajo> may be I got it inverted 14:58:23 <gsagie> sorry 14:58:25 <gsagie> back 14:58:29 <ajo> hi gsagie 14:58:34 <ajo> we're near to the top of the hour 14:59:00 <gsagie> egress is more usefull sadasu 14:59:11 <irenab> ajo: i light of new feature request psocess 14:59:33 <gsagie> ok, anyone got to check the OF1.3 metering support in OVS? 14:59:41 <gsagie> i will try to find out for next meeting (or before) 14:59:47 <ajo> thanks gsagie 14:59:54 <irenab> process, do you plan to continue over existing spec till it gets accepted? 15:00:01 <ajo> #action vikram__ to check ingress_policing_rate 15:00:13 <ajo> #action gsagie to check OF1.3 metering and ratelimiting support in OVS 15:00:29 <ajo> irenab, yes, it's a good field for discussion 15:00:54 <ajo> then, depending on what's decided, we could move it to devref 15:01:05 <ajo> or shrink it / split it 15:01:13 <ajo> does it sound reasonable? 15:01:36 <irenab> ajo: yes 15:02:12 <ajo> ok let's endmeeting for today 15:02:21 <ajo> #endmeeting