14:00:17 #startmeeting neutron_qos 14:00:18 Meeting started Wed Jun 17 14:00:17 2015 UTC and is due to finish in 60 minutes. The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:21 The meeting name has been set to 'neutron_qos' 14:00:29 hi 14:00:35 hi ;) , let's leave a couple of minutes for people to join 14:00:37 hi moshele :) 14:00:40 hi irenab :) 14:00:43 Hi ajo 14:00:49 hi Ramanjaneya_ :) 14:01:01 HI Ajo 14:02:11 https://etherpad.openstack.org/p/neutron-qos-jun-17-2015 14:02:16 #link https://etherpad.openstack.org/p/neutron-qos-jun-17-2015 14:02:36 ok, we can probably start (ping sc68cal , ) :) 14:02:49 hi 14:02:52 We don't have an specific agenda for today, I just planned to track the ongoing work 14:03:01 hi mohankumar 14:03:05 #topic ongoing work status 14:03:15 o/ 14:03:23 hi ihrachyshka :) 14:04:04 irenab was willing to take some tasks from the service plugin / api, and I have to split that work 14:04:31 afterwards I will write some actual code for the generic rpc callbacks, to see how they fit 14:04:57 #link https://review.openstack.org/190635 14:05:09 Ramanjaneya_, any update on your side? 14:05:17 sorry for joining late everyone, i'll ping sc68cal 14:05:47 i have a spec that we are drafting and would def appreciate feedback on for dscp that is very similar to your bandwidth spec, let me find the link 14:05:56 have you had time for looking into the DB models / etc? otherwise we need to look for help on that to not block the service plugin/api 14:06:04 vhoward, nice! 14:06:28 https://review.openstack.org/#/c/190285/ 14:06:36 ajo, Qos neutron client changes completed.. 14:06:37 https://review.openstack.org/#/c/189655/ 14:06:51 vhoward, we're setting everything under the topic neutron-qos to find them all together: https://review.openstack.org/#/q/topic:neutron-qos,n,z could you update your topic? :) 14:06:55 i −1'd us until we are out of draft mode or get enough feedback to make it official 14:07:06 vhoward thanks :) 14:07:28 also i still need to link as a dependency to the main qos api spec/blueprint 14:07:49 ahh thanks Ramanjaneya_ , I see a new patchset, I will review 14:07:54 we hope to finalize monday but appreciate feedback until then 14:08:00 yes i can update my topic, thanks ajo 14:08:30 #link https://review.openstack.org/#/c/190285/ 14:08:37 #link https://review.openstack.org/#/c/189655/ 14:08:46 #link https://review.openstack.org/#/q/topic:neutron-qos,n,z 14:09:15 Ramanjaneya_, do you have time to look into the db models, or shall we look for help there? , not sure if you irenab could be available to speedup that part while I split 14:10:18 also, if we use the generic rpc, we may put a versionedobject layer on top of the models 14:10:19 Yes ajo..We will check DB model. vikram also might come this Friday 14:10:46 Ramanjaneya_, ack, it's on the critical path, because it's needed by other parts, so we shall resolve that very fast 14:11:52 Ramanjaneya_, looking at the client side, I'd look into how to make all the arguments that go after --type, dependent on the type we provide, 14:11:54 if that's even possible 14:12:20 for 1 type, it's ok 14:12:36 but we don't want the help to show 200 arguments for all the available rule types 14:12:45 being all optional then.. 14:13:01 but let's discuss that on the client code review 14:13:38 we also need sc68cal to set the experimental job when he can, so we can run with the service plugin properly installed 14:14:20 OK Ajo .. will take irenab help and focus this on priority 14:14:27 k updated the topic ajo, thanks 14:14:41 hello 14:14:54 hi gsagie :) 14:15:19 gsagie also offered help, 14:15:27 gsagie, did you have time to look at moshele work? 14:15:36 moshele, how's that progressing? I like how it looks 14:16:15 ajo: I didn't progress match for the latest patchset I posted 14:16:23 from 14:16:28 vhoward, btw, since recently you need to submit an RFE and slimmed down spec (looking for the link from last neutron meeting) 14:16:30 not yet, i will only be available next week, but talked with moshele in the Israeli Openstack and offered to also help on that 14:16:42 the original plan was to start making the OVS agent implementation 14:17:23 gsagie, ok, probably it makes sense to develop the library bits to handle QoS independenlty, and then we plug them in the agent logic design? 14:17:32 yep 14:17:35 gsagie, (just thinking about isolating your work so you can make progress) 14:17:38 thats what i had in mind 14:17:43 gsagie++ 14:17:44 :-) 14:17:59 i will have something ready for the sprint 14:18:11 so we can work on hooking things up 14:18:17 vhoward, the new RFE process: https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst 14:18:19 #link https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst 14:18:19 ajo: ah okay thanks for the info on RFE and slimmed down spec 14:18:26 we will get on that 14:19:02 ajo: you had a link with some of your experiments with OVS, could you resend it? 14:19:07 vhoward, it's just cutting down the spec, and filling a bug, 14:19:30 vhoward but feel free to proceed with the code when you see it's possible even if not approved, as we said, so it will be in shape to merge as soon as possible :) 14:19:31 works for me just wanna make sure we do it correctly 14:19:41 vhoward, but I know general QoS work is blocking that :) 14:19:53 vhoward, ack, I will read the current spec and comment 14:20:00 gsagie, sure, 1 sec 14:20:16 hopefully we can help some with that also ;D 14:20:31 gsagie: https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_traffic_shapping.sh 14:20:32 #link https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_traffic_shapping.sh 14:20:35 thanks! 14:20:58 ajo I think we need to close service plugin -> agent flow and ml2 plugin -> agent flow and see how it fit with the Generic RPC mechanism 14:21:13 gsagie, it's very simple, later we may want to upgrade it with enqueue openflow actions (when we tackle traffic/flow classifiers in the future) 14:21:40 moshele, yes, we need to put all the pieces together ASAP 14:21:49 if that's what you mean 14:21:59 yes 14:22:06 we need db to do the service plugin API 14:22:50 also the validation part in ML2 and service plugin 14:23:11 moshele, what do you mean by validation part? (validating rules/available rules?) 14:23:34 ihrachyshka has been working on that 14:23:48 yes it can come for ML2. or service plugin when the port is bounded 14:23:55 he has an initial design, but may need to be extended when we have dscp in place, for example 14:24:07 as it only reports the common subset of rules supported by all ml2 drivers 14:24:30 ajo, well, doesn't it depend on scheduler work? 14:24:49 ihrachyshka, probably we can resolve that when we have a working prototype 14:24:57 and look at the cases of different mechanism drivers, 14:24:58 we should not assign a qos-enabled port to a node that is not capable to fulfill the needs 14:25:12 I know that we will find a way to resolve it in a nice way 14:25:29 ihrachyshka, sometimes a node could be exposing sr-iov ports, and normal OVS ones , right moshele? 14:25:43 but if the port is going to be sr-iov ... no dscp rules, 14:25:52 if the port is going to be ovs... dscp rules = yes 14:26:00 right 14:26:04 we may need to resolve the issue at plug time, for example, failing the plug 14:26:19 then we also have updates... 14:26:21 which are trickier 14:26:27 the port could be already plugged... 14:26:28 correct 14:26:43 and then what do we do? , do we stop the rule update because we can ask ml2 somehow ? 14:26:54 or do we accept the rule, and then report the port as failed? 14:27:07 when agent tries to configure it properly.. and it fails? 14:27:11 the port could be working... 14:27:16 but reported as failed... 14:27:19 I guess that could work? 14:27:31 that's where the port status thing comes... 14:28:23 I believe we can find a reasonable way to solve it, and of course, improve it over time 14:28:49 it doesn't have to be right now, I believe we can explore those cases when we're ready 14:28:52 IMO, at least.. 14:29:16 probably I'm too dumb to think so far ahead :) 14:29:17 :-) 14:30:14 ok, ihrachyshka , moshele , vhoward , gsagie , Ramanjaneya_ mohankumar , irenab 14:30:26 anything you think it's worth discussing now, or that I could be missing? 14:30:27 ajo, a node is then should be represented as two separate entities with their own resources. anyway, moving forward. 14:30:51 ihrachyshka, probably that'd be the different agents? 14:30:57 ihrachyshka sriov agent, and ovs agent? 14:31:02 yeah, that's my expectation 14:31:08 makes sense 14:31:24 OR agent will know how to plug the proper one, if it really serves multiple bridges 14:31:41 sorry, bridges -> resource types 14:32:58 ok 14:33:06 the mid-cycle in israel is approaching 14:33:28 for the remote participants across timezones, we could use an IRC channel, and possibly an etherpad 14:33:50 we could try to use it as a log of what's happening, and who's doing what 14:33:56 so we could coordinate, 14:34:02 keep the stuff that needs review 14:34:24 and prioritise such reviews 14:34:28 i like that idea, i think lots of folks are listing remote and cannot travel 14:34:46 vhoward, yep, not sure if there are better ways to do it given the timezone differences 14:34:55 may be we could setup a video meeting once a day 14:35:00 in an overlapping time 14:35:24 probably we'd kill anyone on the east coast by waking up to early each day ;D 14:35:29 but it's only 3 days! ;D 14:35:34 +1 naw we will be fine 14:35:36 hehe 14:35:49 thanks vhoward , we will try that, 14:36:08 vhoward: try bluejeans for demo, that connects to the redhat conference rooms very easily 14:36:16 vhoward: you should make an effort to come.. after all it is the holy land 14:36:19 let me link a demo site so you can setup the stuff on advance 14:38:02 #link https://redhat.bluejeans.com/10305/3230/browser 14:38:06 vhoward ^ 14:38:24 disclaimer, on OSX I only managed to make it work from Safari, chrome's plugin doesn't work 14:38:27 i'm scheduled to attend, but you all are scaring me now lol 14:38:30 firefox could work, but didn't try 14:38:40 thank you i'll try it out 14:38:40 vhoward: lol :) 14:40:20 :-) 14:40:25 works! 14:40:29 nice :) 14:41:03 ok, if there's no other thing we could close the meeting 14:41:38 Ramanjaneya_, let's try to prioritize DB models, let me know if you need any help from me, irenab, or if we need to ask for more volunteers 14:42:09 feel free to ping me on IRC, 14:42:12 sure..will look DB model as priority 14:42:30 I will propritize splitting the service plugin & callbacks, and api patches, so irenab could take any of then and make separate progress 14:42:34 will ping in IRC if any help further 14:44:22 ok, thank you guys/gals 14:44:29 #endmeeting