14:03:34 <ajo> #startmeeting neutron_qos
14:03:35 <openstack> Meeting started Tue Apr 21 14:03:34 2015 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:38 <openstack> The meeting name has been set to 'neutron_qos'
14:03:43 <moshele> ajo: I can send ireanb sms
14:03:57 <ajo> moshele, thanks :)
14:04:02 <ajo> #topic Announcements
14:04:09 <sc68cal> ajo: pong
14:04:16 <ajo> hi sc68cal  :)
14:04:24 <ajo> #link #link https://etherpad.openstack.org/p/neutron-liberty-qos-code-sprint
14:04:29 <ajo> woops :) double link :)
14:04:31 <ajo> #link https://etherpad.openstack.org/p/neutron-liberty-qos-code-sprint
14:05:06 <ajo> I guess most of you are already aware of the qos code sprint Red Hat is proposing, feel free to signup if you believe you can come, or collaborate remotely.
14:05:49 <ajo> but, we have specs to get merged, and a lot to agree before a code sprint can happen :)
14:06:02 <ajo> any question about it? :)
14:06:25 <ajo> ok, let's move on
14:06:37 <moshele> ajo: irenab will join shortly
14:06:49 <irenab> hi
14:06:56 <ajo> hi irenab !! :)
14:07:01 <irenab> sorry for being late
14:07:08 <ajo> np :)
14:07:12 <ajo> just in time
14:07:15 <ajo> #topic updated spec
14:07:24 <ajo> #link https://review.openstack.org/#/c/88599/
14:07:36 <ajo> I have updated sc68cal spec, with a few ideas about splitting the initially proposed model
14:08:02 <ajo> into QoSProfiles, composed of QoSPolicies
14:08:43 <ajo> for ratecontrol/bandwidth limiting, may be it's too much, but I wanted to make the models/api to grow without big changes, or breaking backward compatibility of the API ends in the future.
14:08:50 <aveiga> ajo: what's the problem you're attempting to solve with that setup?
14:09:11 <ajo> aveiga, for example, there were concerns in previous models about applying several profiles to one port/network
14:09:27 <ajo> aveiga, for example, you could like to mark packets + bandwidth limit them...
14:09:49 <ajo> or you may want (in the future), to be able to write QoSPolicy rules which target traffic selectively
14:10:05 <sc68cal> ajo: cbits and vhoward- from Comcast are also from Comcast and interested in the QoS work
14:10:09 <ajo> for example... tcp.port=80
14:10:27 <ajo> aveiga, does it sound reasonable?
14:10:31 <aveiga> ajo: I see where you want to go with this
14:10:55 <ajo> aveiga, something like security groups, but for applying QoS policies to different types of traffic
14:11:05 <aveiga> you can have a slective overload of that setup, where ports on tenant x by default have forced ratelimiting, but maybe they also want to add a mark for some traffic
14:11:13 <irenab> ajo: on same neutron port, right?
14:11:20 <ajo> irenab correct,
14:11:46 <aveiga> the fun part is the collapsing logic, because if they're doing different things it's fine, but some things are one property only or may be mutually exclusive
14:11:54 <ajo> exactly
14:11:54 <aveiga> I suppose that's an implementation detail though
14:12:13 <aveiga> we need a way to provide the feedback on failure, though
14:12:20 <ajo> I was going to get into that, we may need some sort of logic to check we can add an extra rule that works with previous ones in the profile
14:12:36 <irenab> aviega: agree, and this may sometimes depend on QoS backend implementation
14:12:42 <aveiga> it would be a poor UX to allow them to try setting two DSCP marks against the same port withotu a way to tell them why it won't work or which one was actually applied
14:13:01 <ajo> aveiga, but for a first iteration, it seems only ratecontrol/bandwidth limiting is getting accepted by neutron-drivers (to control how we design/grow the feature),
14:13:11 <aveiga> :(
14:13:28 <ajo> aveiga, anyway, I'm all for it, if we finish the first steps,
14:13:37 <aveiga> ok
14:13:39 <ajo> let's go ahead and start developing the U/S dscp part
14:13:56 <irenab> ajo: what is your intention regarding ref implementation?
14:13:58 <ajo> it's probably not going to be too complicated with comcast code + the bare bones in place
14:14:16 <aveiga> as long as we can get the api nailed down, we can port our stuff over and merge later
14:14:58 <ajo> aveiga, sounds good, may be, if you want you can work in a follow up spec to the current one, to extend with dscp, so we know how it looks
14:15:04 <vhoward-> yes data model and api would like to see that solidified in spec, we can help
14:15:16 <irenab> I think if API will open enough, different plugins may have various options to support, sometimes richer than ref implementation
14:15:47 <ajo> irenab, about ref implementaion, I have another point in the meeting, give me 1 min :)
14:15:53 <ajo> irenab, I agree
14:15:55 <vhoward-> +1 irenab
14:15:59 <ajo> that comes to another question,
14:16:08 <ajo> we're defining the bandwidth limiting fields,
14:16:33 <ajo> but do you believe we should accept, other fields?
14:16:49 <irenab> ajo: at API level?
14:17:00 <ajo> I guess, accepting different fields without control could lead to non interoperable policy rules
14:17:25 <ajo> irenab, talking about the parameters dict: https://review.openstack.org/#/c/88599/7/specs/liberty/qos-api-extension.rst
14:17:29 <ajo> line 125
14:18:36 <ajo> I have defined as much as I can think of, but for example, max_latency_ms can't be applied to ovs (AFAIK) but it was proposed on previous versions of the spec.
14:18:39 <ajo> sc68cal, do you recall why?
14:19:05 <irenab> ajo: In my opinion there is a difference if we require this at API level or at the implementation/db level
14:20:08 <ajo> irenab, what do you mean
14:20:09 <ajo> ?
14:20:22 <sc68cal> ajo: That was proposed in the spec for the linux bridge implementation for rate limiting
14:20:29 <ajo> ah, ok API / vs impl
14:20:30 <sc68cal> since it was using tc as the driver
14:20:48 <aveiga> it might be a good idea to abstract out the api calls as high as we can
14:20:57 <ajo> aha, sc68cal , so tc supports latency settings
14:21:02 <sc68cal> ajo: yes
14:21:06 <irenab> There are validations that can be done at API level, so from API perspective, I think there should be ‘key’, ‘val’  pairs
14:21:14 <sc68cal> aveiga: the problem with making this all abstact is how do we validate
14:21:19 <aveiga> yup
14:21:26 <ajo> I agree with aveiga , we may abstract the parameters as much as we can, but...
14:21:33 <irenab> but where the implementation is involved , we can check the supported ‘keys’ only
14:21:41 <ajo> every implementation is a bit different
14:21:49 <ajo> irenab, that makes sense,
14:22:02 <ajo> may be we can check the default keys, and leave room for non-default ones
14:22:15 <matrohon> backend should report what fields they support?
14:22:23 <ajo> so every vendor could leverage extra capabilities
14:22:24 <irenab> in my opinion we should not close API for only current known list
14:22:39 <irenab> matrohon: +1
14:22:49 <ajo> irenab, ok, we may need to check that with neutron core/drivers to see if it's ok, are we doing such thing in other places?
14:23:10 <ajo> matrohon, or we can pass parameters to backend for checking
14:23:25 <irenab> I gues extra_dhcp_opts are similar in this sense
14:23:29 <matrohon> it looks like extension suppport for plugins
14:23:39 <ajo> aha
14:24:30 <ajo> #action ajo allow extra settings in the parameters dictionary to be checked by the plugin/specific implementation.
14:24:33 <matrohon> ajo : calling a backend during a transaction should be avoided
14:24:49 <ajo> matrohon, true
14:25:05 <ajo> in that case, we can check available parameters with backend at start
14:25:18 <aveiga> extensions could be interesting, is it possible to pass an object as the value in a k/v pair? That way you might be able to provide, say, min and max bandwidth and min/max latency in the "bandwidth" key
14:25:37 <ajo> but ok, I guess this is all implementation detail we can discuss over the spec.
14:26:01 <matrohon> ajo : +1
14:26:06 <ajo> is it ok to discuss the details over the spec?
14:26:09 <ajo> thanks matrohon
14:26:10 <cbits> ajo +1 on flexable and letting the backend define the validation.
14:26:48 <ajo> #topic reference implementation
14:27:17 <ajo> (irenab, I had another point later for the service-plugin vs mechanism-driver or other ways...)
14:27:30 <irenab> ajo: ok :-)
14:27:47 <ajo> about reference implementation, I guess it should go in ml2-ovs, I know irenab you were interested in ml2-sriov, not sure if it's yet the case
14:28:20 <ajo> sc68cal, in the previous spec, there was somebody proposing ml2-linuxbridge which I guess makes sense too if we have people willing to do it
14:28:30 <irenab> ajo: I think SR-IOV is  in moshele hands now
14:28:38 <ajo> moshele +1
14:28:38 <ajo> :)
14:28:50 <sc68cal> ajo: yes, so we would have a ml2-lb and ml2-ovs implementation ready for revival
14:28:52 <vhoward-> we were interested in ml2-ovs also
14:29:07 <vhoward-> the mech driver
14:29:15 <sc68cal> I think there was also a ml2-ovs rate limit impl. floating around too
14:29:31 <moshele> ajo: I will do the ml2-sriov
14:29:37 <irenab> waht QoS functionality is going to be implemented? only rate limit?
14:29:37 <ajo> irenab, I recall your design where a few parts could be reused across several ml2-agents, if I didn't get it wrong
14:30:03 <irenab> ajo: right. The idea was to extend existing l2 agents in a reusable way
14:30:16 <ajo> at least ratelimit, yes
14:30:23 <ajo> that's the recommendation from neutron drivers
14:30:28 <ajo> and PTL
14:30:57 <ajo> if we put testing in place, + a good design, we have a good amount of work ahead,
14:31:18 <ajo> but I'm all for writing more policy types if we finish early
14:31:35 <vhoward-> irenab: no we are looking to mark traffic not just rate limit
14:31:37 <matrohon> irenab, ajo : are speaking about a modular agent revival?
14:32:07 <irenab> matrohon: related to this, right
14:32:09 <cbits> We are also looking to filter traffice based on DSCP marking
14:32:18 <moshele> ajo: for the ml2  extension_manager we will need this https://review.openstack.org/#/c/162648/ change as well
14:32:29 <vhoward-> we are looking to blueprint ml2-ovs mech driver for qos so we will keep you all in the loop on that to what cbits said
14:32:38 <irenab> cbits: with upstream OVS impementation?
14:33:03 <cbits> yes
14:33:49 <ajo> moshele, It looks like it eventually get merged as it's fixing a bug, right?
14:33:55 <ajo> it will
14:34:00 <irenab> from the API perspective, it makes ense to have all these options (and maybe more) available from the beginning, while only subset can be implemented in the first iteration
14:34:27 <ajo> irenab, which options?
14:34:42 <moshele> ajo: yes it was freezed because of kilo, but we will push it now
14:34:43 <irenab> mentioned by cbit
14:35:04 <ajo> cbits, ack :)
14:35:09 <irenab> DCSP marking,..
14:35:09 <ajo> I missed cbit commit about DSCP filtering
14:35:16 <sc68cal> cbits: that's out of scope
14:35:28 <aveiga> filtering is an SG change, not a QoS change
14:35:35 <ajo> it's related, looks more like a security group change, correct
14:35:39 <aveiga> or rather, port security
14:35:42 <sc68cal> that's an extension that you guys to the sec group API, that you're going to have to carry
14:36:12 <cbits> cool
14:36:19 <ajo> they could propose an extension to the security groups API to have a dscp field U/S
14:36:49 <ajo> #topic access control / ACLs
14:36:51 <cbits> ajo +1
14:37:10 <ajo> in previous "pre-meeting" we discussed about access control to QoS profiles
14:37:12 <sc68cal> ajo: extension of an extension. yaaay. :)
14:37:23 <ajo> sc68cal or just update the extension :)
14:37:48 <irenab> ajo: kevin updated the RBAC  spec https://review.openstack.org/#/c/132661/ to be generic
14:37:49 <ajo> we believe in the feature we could leverage the design of RBAC to control QoS profiles access by tenants
14:37:57 <ajo> #link https://review.openstack.org/#/c/132661
14:38:04 <ajo> yeah, I saw it, great news :)
14:38:17 <ajo> I need to read it through, I didn't have time yet
14:38:35 <sc68cal> I think that's very good news, but let's not stretch ourselves too much for first iteration
14:38:50 <ajo> but, for this cycle, there was a genera agreement, that having the admin controling the policies/rules setting to ports/networks itself
14:38:57 <irenab> ajo: It looks suitable for managing QoS profiles
14:38:58 <ajo> and disallow it on tenants for now
14:39:07 <sc68cal> ajo: admin/owner?
14:39:31 <ajo> I'd say admin only for now, but it's just a matter of configuring the policies
14:39:59 <ajo> for example, you don't want tenants randomly making bandwidth changes to modify a setting done by admin
14:40:32 <sc68cal> ajo: true, but we can do checks for if the network is shared
14:40:36 <ajo> but, if anybody needs a change on that, they only need to modify /etc/neutron/policy.json
14:40:38 <sc68cal> then disallow
14:40:53 <sc68cal> ajo: good point.
14:41:15 <ajo> sc68cal, we can think of probably common defaults, but everybody is going to make different uses, I guess
14:41:23 <ajo> some operators may not want to rely on admin to set profiles
14:41:33 <sc68cal> ajo: true, but you make a good point, policy.json is easy to change
14:41:34 <ajo> and some operators may not want tenants to modify / set new profiles, I guess
14:41:42 <sc68cal> ajo: and hey, it's actually getting some documentation, finally!
14:41:46 <ajo> sc68cal, we could provide instructions on how to do it
14:41:55 <ajo> sc68cal, really? :D :-)
14:41:56 <ajo> that's good
14:42:15 <ajo> ok
14:42:20 <ajo> a tiny topic before we jump into a bigger one
14:42:33 <ajo> #topic ratelimiting vs ratecontrol
14:42:59 <ajo> I was thinking that ratecontrol "type" could be used for both min/max rate if I'm not missing anything
14:43:42 <ajo> not sure if we need separate types to define traffic guarantees
14:44:01 <ajo> or just have a "min" field, specifying what's the minimum bandwidth we're providing on a port
14:44:37 <ajo> does it sounds reasonable/unreasonable?
14:44:48 <sc68cal> little fuzzy on difference
14:44:57 <sc68cal> care to educate?
14:45:30 <ajo> from the ovs/linux-htb point of view, having it together, makes the "min" parameter meaningful, and we can control priorities over ports/bandwidth..
14:46:07 <ajo> ok, I see no -1's at least :-), I will change it on the spec, but feel free to complain or ask me to change it back
14:46:15 <ajo> let's move on
14:46:35 <ajo> #topic service-plugin, or simple mechanism driver
14:46:43 <ajo> irenab, do you want to lead this one?
14:46:52 <irenab> ajo: ok
14:47:01 <ajo> thank you :)
14:47:22 <irenab> the question is if the QoS profile/policy management should get its own service or be part of the Core plugin
14:48:18 <irenab> I tend to see it belongs to service plugin, potentially with different providers
14:48:20 <sc68cal> Not sure if this is relevant, but I'd say we should get the API extension into core then have our own repo to rapidly iterate
14:48:39 <sc68cal> similar to all the *aaS repos
14:49:01 <irenab> sc68cal: thats what I had in mind
14:49:13 <sc68cal> ok, so guess I'm in the service plugin camp
14:49:15 <ajo> Well, I'm not 100% convinced we need a separate repo here, at least for the start
14:49:44 <irenab> the extension definition can be hosted in the same repo as well
14:50:00 <ajo> I'm happy about the design advantages that come with making it a service plugin,
14:50:28 <ajo> and it's tightly coupled to the reference implementation of the ovs-agent which lives on tree
14:50:30 <sc68cal> irenab: are you sure? last I checked the core repo still had the extensions for all the *aas stuff
14:50:47 <sc68cal> or was that just a procedural thing, where they hadn't split them out yet
14:50:59 <irenab> sc68cal: not for new introduced ‘services’, like l2gw
14:51:20 <matrohon> since it apply to core resources, I feel it's more in the scope of Core plugin extension
14:51:45 <ajo> matrohon, that's my feeling too
14:51:48 <irenab> I guess its just easier to maintain both api and impementation together, but do not have strong opinion where to put it.
14:51:59 <ajo> irenab, sc68cal , could you enumerate advantages of making it a service plugin instead?
14:52:28 <sc68cal> ajo: Ideally it'd allow us to iterate in our own repo, have our own cores and such
14:52:33 <ajo> we're basically setting parameters of the networks and ports
14:52:43 <sc68cal> ajo: the trouble is - as you pointed out, the agents
14:53:29 <ajo> sc68cal, yes, but I believe it's going to become an important feature for many telcos/operators, and it modifies parameters of basic resources like ports,
14:53:42 <irenab> ajo: I think mostof the advanced services eventually apply to core resources
14:53:44 <ajo> I'm not sure if that fits on the category of an advanced service living on a seperate repository
14:54:00 <ajo> irenab, well, they make use of them...
14:54:03 <ajo> but do they modify them?
14:54:11 <ajo> may be FwAAs modifies routers,
14:54:12 <irenab> but all the policies/profiles management is quite stand alone logic
14:54:32 <sc68cal> Let'
14:54:48 <sc68cal> Worst case we can do a little research on the service plugin
14:54:51 <irenab> we eventually map port to some profile UUID
14:55:09 <sc68cal> right now most of the existing code ties right into the core
14:55:09 <ajo> irenab, sc68cal , matrohon , what do you think about looping in cores in next neutron meeting, and see how they think about it
14:55:11 <ajo> ?
14:55:15 <sc68cal> ajo: good idea
14:55:22 <sc68cal> or a ML thread
14:55:28 <ajo> ML should work too
14:55:28 <sc68cal> ml thread might be better
14:55:36 <ajo> probably better
14:55:38 <ajo> sc68cal +1
14:55:47 <irenab> I would vote for service plugin for clean separation of concerns, quicker iterations
14:56:03 <matrohon> you'll have to have a dedicated MD for the service plugin to be aware of any changes on a port/networks?
14:56:14 <irenab> the recent spirit to spin every possible part out :-)
14:56:38 <matrohon> armax introduced a registry mechanism that can be reused too
14:56:45 <ajo> yes
14:56:50 <irenab> matrohon: callback?
14:56:56 <ajo> matrohon, the callbacks, right?
14:56:57 <ajo> :D
14:57:05 <sc68cal> irenab: agreed - we just have to figure out how to get the agents to work with the qos service with no code changes to core
14:57:05 <matrohon> yep
14:57:42 <ajo> sc68cal, fwaaS extends the l3-agent, reight?
14:57:43 <matrohon> sc68al :  this is the scope of the module agent work in progress...
14:57:44 <irenab> we tried to solve it in some AgentExtension way
14:57:48 <ajo> but I believe that way is not very sustainable
14:57:58 <ajo> we may need extending the agents in a more dynamic way
14:57:59 <sc68cal> ajo: I'd have to check how they do that
14:58:05 <matrohon> currently, there is no way to extend agent (LB or OVS)
14:58:11 <sc68cal> i know vpnaas just runs a whole new agent that inherits from the l3 agent
14:58:14 <sc68cal> it
14:58:16 <sc68cal> is nasty
14:58:18 <ajo> yes, matrohon , correct
14:58:19 <matrohon> the l3agent is easily extensible since kilo
14:58:29 <ajo> ok
14:58:29 <matrohon> but not the l2agent
14:58:35 <ajo> let's talk about it in the mail thread
14:58:38 <ajo> 1 min left :)
14:58:55 <irenab> matrohon: sounds about the right time to make a change :-)
14:59:04 <matrohon> irenab : +1000
14:59:09 <ajo> my opinion is more on keeping it to the core, but I'll make an impartial thread start, so we can discuss freely
14:59:25 <ajo> ok
14:59:33 <matrohon> rosellab has been very active on the agent, but none of her improvment has merge in kilo
14:59:35 <sc68cal> core is tough, they're splitting reference from neutron
14:59:41 <ajo> I also had a request from salv-orlando , to share our proposed API with operators and telcos
14:59:44 <ajo> to get feedback
14:59:53 <sc68cal> for the neutron-lib work
14:59:59 <ajo> since people complains generally about neutron API usability
15:00:05 <irenab> ajo: souds great, the earlier the better
15:00:07 * sc68cal trying to get as many words in 60 seconds
15:00:11 <ajo> :D :D
15:00:16 <salv-orlando> it's not a strict requirement. but it is to avoid previous mistakes
15:00:24 <salv-orlando> like the one we made with load balancing apis
15:00:25 <ajo> salv-orlando +1
15:00:28 <sc68cal> ++
15:00:38 * sc68cal pokes aveiga
15:00:52 <irenab> ajo: any work items for next week?
15:00:53 <ajo> ok, I believe we shall free the channel
15:00:57 <aveiga> sorry, catching up post power outage
15:01:09 <sc68cal> aveiga: you're our telco guinea pig
15:01:17 <ajo> let's discuss over #openstack-neutron-qos
15:01:20 <ajo> #endmeeting