14:01:23 #startmeeting neutron_qos 14:01:24 Meeting started Wed Jun 3 14:01:23 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:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:28 The meeting name has been set to 'neutron_qos' 14:01:50 #topic Where are we 14:01:56 hi 14:02:02 hi :) 14:02:10 #link https://etherpad.openstack.org/p/neutron-qos-jun-3-2015 14:02:28 with the help of irenab , we have put an interactive agenda in etherpad 14:02:34 with some design details 14:02:37 and some points for today :) 14:03:04 please name yourself in the top right icon of the etherpad before commenting :) 14:03:28 ajo: are you referring to this etherpad/ https://etherpad.openstack.org/p/neutron-qos-api-preview 14:03:49 sadasu, https://etherpad.openstack.org/p/neutron-qos-jun-3-2015 14:04:08 thanks ihrachyshka 14:04:10 ihrachyshka: thanks! 14:04:17 ok 14:04:34 so, we got the API / service plugin spec approved 14:04:40 https://review.openstack.org/#/c/88599 14:04:53 and we have a follow up addressing some final comments: https://review.openstack.org/#/c/187513/ 14:05:04 great 14:05:09 ajo, anthony and i will be working on finishing up initial drafts for specs tomorrow around dscp and will link them for everyones review 14:05:26 we also have specs for ML2/OVS: https://review.openstack.org/#/c/182349/ and ML2/SR-IOV https://review.openstack.org/#/c/187895/ 14:05:36 vhoward, great, 14:05:52 do we need to raise RFE for new specs 14:05:54 please note the new RFE mechanism in place 14:05:54 beside specs, is there any code? 14:06:24 RFEs are basically to prevent you from writing a spec for nogthing 14:06:27 nothing 14:06:34 but still, I believe the spec is valuable in our context 14:06:45 in some cases (like this) you could not be required even to write a spec 14:07:04 and just a simple devref explanation of what do you want to do 14:07:10 ihrachyshka: no code yet, we will get to organize that by the end of this meeting 14:07:25 ihrachyshka, or was it a question to vhoward ? 14:07:34 I believe they have some code they can reuse 14:07:38 ajo, no, your response is what I looked for 14:07:47 ihrachyshka ack, thanks 14:07:57 . 14:08:18 yesterday on neutron's meeting, we raised the openstack/neutron vs openstack/neutron-qos question 14:08:27 hi armax ;) 14:08:50 mestery suggested a feature branch, and we need to analyze work that out during this week 14:08:54 ihrachyshka: there is code for dscp marking 14:08:55 #link http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-06-02-14.01.log.html#l-293 14:09:53 one thing that may complicate the OVS work - the new reference implementation split - https://review.openstack.org/#/c/176501/ 14:10:22 sc68cal: I guess it will impact SR-IOV as well 14:10:24 a feature branch, is basically a branch of /neutron where we do all the work related to QoS, and when stable, that's finally merged to /neutron, or ... spun out (I'd definitely avoid feature branches if that's the final outcome and jump straight into separate repo) 14:10:43 ajo 14:10:49 because a later spin out may introduce all the CI overhead later in the cycle 14:10:56 ajo: is it in stackforge 14:11:08 vikram, starckforge first, then under neutron umbrella 14:11:17 which means openstack/..... as far as I understood 14:11:23 ihrachyshka, am I right? 14:11:46 vikram, talking about out of tree plugin, right? 14:12:01 ajo: yes 14:12:02 sc68cal: yes 14:12:14 sc68cal, that's true, OVS spin out may complicate things, but, we just need to track that 14:12:17 ajo, I guess so 14:12:45 ok, any question or concern about this? 14:12:47 * sc68cal gets out his butterfly net to chase all these pieces of neturon that are flying out of the main tree 14:12:58 sc68cal lol 14:13:24 sc68cal, puzzle with 1000+ pieces, yea 14:13:50 ajo: so the patch i submitted for neureon-qos project will be approved? 14:13:54 sc68cal, if finally we spin out ref implementation, I have proposed myself to help a bit with it, so we have better track ourselves 14:14:04 vikram, no 14:14:34 unless there is any change in the end... 14:14:38 but no, so far.. 14:14:47 ajo: nice :) 14:15:14 #topic QoS design points 14:15:36 irenab, do you want to talk about this one? :) I can interleave... 14:15:46 ajo: sure 14:15:55 so Lets start from server side 14:16:22 we will have QoS server plugin to manage QoS policy/rules 14:16:53 we have QoS policy to port/ent mapping API 14:16:59 ajo: just to summarize from the previous discussion: qos api changes in a seperate feature branch (maybe) and the changes to OVS/SR-IOV refernce ML2 plugins will be in their respective stackforge repos 14:17:18 sadasu, correct, as they will be spun out... 14:17:38 back to design? 14:17:41 yes :) 14:17:59 yes irenab! 14:18:03 so for qos policy mapping lokks like there are 2 options 14:18:16 1. support in qos service plugin 14:18:25 2. ML2 extension 14:18:45 with option 1, it looks like more consistent way 14:19:00 with option 2, more easy way 14:19:19 irenab: what do you mean by more consistent way 14:19:20 with 1 we pave the way for other plugins 14:19:34 and it's more consistent with the API proposal 14:19:41 all policy UUID resolution into real attribute should be handled by the qos plugin anyway 14:19:52 that means, 14:20:05 irenab: if we got with 1 can the service rpc with L2 agent or we need to implement new agent? 14:20:06 we may extend the port information just with the qos-profile-id but no more details 14:20:34 then the plugin is responsible of talking with the qos service plugin api to fetch the policy and rule details 14:20:42 ajo: right, and the question if we want to do it via Ml2 qos mapping extension driver OR qos plugin 14:21:37 I'd go for 1 14:21:47 and then every plugin can do what it needs to do... 14:22:11 for me 1 lokks more consistent as well, but maybe we need to prototype the workflow to see how to achive it 14:22:19 so we will have separate plugins for OVS/LB/SR-IOV? 14:22:19 irenab: I agree 14:22:44 vikram, no, 14:22:49 all those are drivers within ML2 14:23:22 we may need some differentiation in the QoS pplugin, since capabilities may differ 14:23:37 yes, 14:23:45 that's one of the points we need to resolve 14:23:59 my keyboard in a bad mood today :-) 14:24:14 plugin-wise it's very simple to add a mechanism for "plugins" (ML2, a, b c...) to register their available rules... 14:24:37 and then when those rules are created, we can just deny the ones not supported... 14:24:41 but 14:24:47 with ML2, we have one plugin 14:24:55 and many drivers, that can be running concurrently 14:25:14 local, ovs, lb, sr-iov... 14:25:26 not local, sorry 14:25:37 if you see the table in the etherpad 14:25:40 ajo, maybe ml2 could find common set to report as supported 14:25:42 What I am stil questioning is how port-create will deal with port extension supported by service plugin 14:25:45 not all of them have the same capabilities.. 14:25:55 ihrachyshka, yes, that makes sense, and resolves some part 14:26:14 but still 14:26:24 we may have issues: 14:26:48 1) at port binding, if the port is bound to a sr-iov port (can we know that in advance?) 14:26:49 once port-create is invoked with —qos-profile=UUID, port creation will be handled by ML2 plugin 14:27:27 2) at policy modification, for example, if your policy is applied to lots of ports (sr-iov, ovs..) 14:27:48 but you introduce a rule which is not compatible with all ports 14:28:15 ajo: I think your quesion is much more advanced then mine 14:28:35 once ports are bound... may be during port update, ML2 could refuse to accept the new policy... 14:28:50 ajo, you know which drivers are enabled, so the list of rules supported by all of them is predetermined. You can just check whether the new rule is among those. 14:29:05 Iok, 14:29:09 may be we're trying to dig too much in advance 14:29:10 is it possible in current neutron code to support port extensions in different plugins and not in L2 plugin only? 14:29:24 and it's something we could resolve during develpment 14:29:49 irenab, what do you mean? 14:30:49 if we support qos-mapping port extension in qos service plugin, I am not sure if current API framework will handle it gracefully. 14:31:15 port is managed by L2 plugin (ML2) 14:31:17 In order to support SR-IOV we would need that support in hardware, right? There's no OvS/LinuxBridge way of applying QoS to an SR-IOV VM VF 14:31:34 pcarver, correct 14:32:02 irenab, I don't see the issue, but, I guess we can solve this by jumping into a code POC 14:32:06 So the ML2 plugin's vendor specific hardware driver is involved 14:32:10 so for now any port extension if supported by this plugin, and then there are mixins to take care of validations and persistency 14:32:44 irenab, plugins may need to signup for the "qos extension" yet 14:32:50 even if we don't have a mixin 14:32:53 and we do that via callback 14:33:04 that=extension 14:33:11 irenab, doesn't self.mechanism_manager.create_port_postcommit in ml2 pass all the needed info to driver? 14:33:35 ajo: so from the ‘supported_extension’ perspective, qos-mapping will go into ML2? 14:34:15 irenab, we need to provide a generic mechanism for plugins, and then in ML2 we could do it as we wanted 14:34:58 may be I'm missing something, can we POC and resolve this into code to see how things fit? 14:35:18 the point I wanted to raise, that it seems that currently all ‘net’, ‘port’ extensions are supposed to be declared as supported by L2 plugin. We just need to see how to make it work. 14:35:34 with qos service plugin 14:35:50 yes 14:35:53 with other L2 plugins, it is the same 14:36:19 irenab, but qos will be still supported by ml2, it's just that specific rules available may depend on drivers. (or I completely misunderstand the concern) 14:36:58 we need to resolve the specific rules per driver... either we fail/warning on port bind when we discover where/to which driver the port is bound 14:37:27 ajo: also on port update 14:37:34 or... we fail on QoS rules update if there is a port not supporting such rule (we may need to find a reasonable way to do such thing without specific ML2 knowledge) 14:37:37 moshele: correct 14:38:34 if we had more port states, some kind of warning could be sent back to neutron server about the ports with unsupported rules 14:38:55 ihrachyshka: it should work for ML2 with ref implementation, but be possible to leverage by other L2 plugins 14:38:56 I remember somebody was looking into that already 14:39:14 irenab: it should work for all plugins, 14:39:23 ML2 included 14:39:32 ajo: right 14:40:00 irenab, sure. I don't see why it won't work. 14:40:01 but looks like with ML2 there are additional concerns, due to mixed drivers capabilities 14:40:18 yes, if we solve ml2, other plugins are even easier 14:40:25 correct 14:40:45 as we're resolving ML2 first, the mechanism should be there for all in the end 14:40:46 so for the next design concern 14:41:04 Agent side? 14:41:31 there are two tipes of plugins/mech drivers: agent and agent-less 14:41:39 ^types 14:41:58 so we should take care of both 14:42:41 examples of agent-less ML2 drivers? 14:42:50 agent-based will require QoS “extension driver” to deal with qos settings and reporting 14:42:56 ODL 14:43:04 ajo: cisco sr-iov? 14:43:10 thanks :) 14:43:10 opencontrail 14:43:17 ovn 14:44:02 looks like there are more agent-less than agent-based :-) 14:44:07 yep :) 14:44:28 so, the idea of the extension driver, is that you can extend the agents in a modular way 14:44:35 reusing all the RPC communication, etc. 14:44:45 ajo: correct 14:45:04 irenab: I added some notes to the etherpad, but may be is too long for this meeting 14:45:11 for agent-less, we don't do anything specifically, right? 14:45:13 I had an idea on how to have a generic RPC mechanism for all extension drivers 14:45:28 I think both OVS and SR-IOV specs are mentioning some qos driver api that they will implement 14:45:44 and even (later in time) make security groups an extension driver too 14:45:50 +1 14:45:54 there will be a common layer above to make the information available 14:46:05 ajo: can you share your idea? 14:46:17 irenab: yes, line 61 of etherpad 14:46:18 basically 14:46:54 we could use query + subscription to fanout queues to retrieve and register for "SG RULES" "sg-id" info 14:47:04 or "QOS PROFILE" "qos-profile-id" info 14:47:22 then the extension mechanism would receive the messages, and route them to the right extension 14:47:24 which subscribed 14:47:27 also 14:47:51 on the rpc side, the service plugins, or extensions, could register to this common rpc mechanism, saying 14:48:06 "I provide info for SG RULES", "I provide info for QOS profiles" , .... 14:48:29 ajo: PUB/SUB 14:48:34 so when somebody subscribes, it's notified, when somebody de-suscribes, it's notified... and it sends the information as changes hapen 14:48:35 happen 14:48:36 yes 14:49:09 so, we would have common bits at ML2 level for the RPC messages 14:49:28 but then, the service plugin would subscribe to that API saying: "I provide QOS PROFILE info" 14:50:08 even, if we use oslo versioned objects at some point, those could be seralized over the messages... 14:50:15 from rpc server to agents... 14:50:34 does it sound too crazy? or even slightly reasonable? :) 14:50:41 sorry for being late 14:50:49 long meeting :( 14:50:57 hi gsagie :) np, we have minutes :D 14:51:23 looks like nice infrastructure, need to reread though … 14:52:03 it's basically a consumer / provider model ...right? 14:52:05 I think it melds well with the idea of providing rpc responses from the service plugin, the extension manager, and having a common mechanism to communicate extensions info.. 14:52:14 ajo: I like it. But I don't think I've fully absorbed it yet. Definitely seems like a good path. 14:52:27 vikram , yes, with rpc in the middle and fanouts to optimize RPC traffic.. 14:52:46 pcarver, yes, I need to write a devref with more detail 14:52:51 ok 14:53:04 ok, 14:53:20 let's talk about the last point, and lets mature the idea to see if it really makes sense 14:53:34 #topic organizing work 14:53:47 if you go to line 94: https://etherpad.openstack.org/p/neutron-qos-jun-3-2015 14:53:56 ajo: agree with the model the way you have explained it, but not sure if we are missing anything here..your devref would help 14:54:19 sadasu, probably we're missing some detail, unexpected complexities everywhere :) 14:54:44 #action ajo to put the common RPC mechanism to a devref 14:54:52 ajo: +1 14:55:06 can you put your names next to the work points where you feel you could collaborate? 14:55:08 in the etherpad 14:55:22 probably the first step is the DB models 14:56:02 I haven't draw a dependency tree... 14:56:13 but time for liberty is tight 14:56:17 that would be nice 14:56:28 ;) 14:56:34 by the end of august, liberty-3 is closed, and feature freeze comes ;) 14:56:36 winter is coming... 14:56:38 ;) 14:57:09 ajo: will add later, my browser is stuck…. 14:57:25 need bulet for extension too 14:57:37 its different from DB model 14:57:39 ok, just signup or add any work piece I could have missed 14:57:59 how about horizon? 14:58:09 we need to do now? 14:58:16 i think thats a low priority 14:58:34 horizon, right 14:58:37 it's low, but it's important 14:58:38 yes.. but need to deliver right? 14:58:41 let's add the bullet 14:59:04 correct, but some tracking with horizon when we manage to get the API in place will be good 14:59:37 my browser is getting a bit crazy :D 14:59:46 ok, we're at the top of the hour... :) 14:59:59 ok 15:00:07 if you want to talk a few minutes more about work distribution I'll be happy #openstack-neutron 15:00:12 ajo: cli? 15:00:24 irenab: that's the command line client point :) 15:00:34 #endmeeting