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