14:00:34 #startmeeting neutron_qos 14:00:35 Meeting started Wed Jun 24 14:00: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:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:39 The meeting name has been set to 'neutron_qos' 14:00:42 hi 14:00:45 hi :) 14:00:45 o/ 14:00:50 hi 14:00:53 Hi 14:00:56 hi all 14:01:07 hello everyone 14:01:10 o/ 14:01:12 hey 14:01:36 ok, let's give a couple of minutes for anyone missing to join... :) 14:01:39 hi 14:01:44 o/ 14:01:56 today it's irena's birthday so she won't be around, Irena, Happy Birthday when you read this! ;) 14:02:25 Happy Birthday Irena 14:02:38 happy bday! 14:02:48 happy cake day! 14:02:56 ok I guess we can start, I didn't put an agenda for today, I just wanted to revise the current status of work, and prepare for the QoS sprint next week :) 14:03:00 Happy Birthday ! 14:03:28 Happy Birthday Irena : ) 14:03:40 I've seen a lot of progress in DB models, and neutron client, thanks Ramanjaneya , vikram and huawei india folks! ;) 14:03:45 any comments about this? 14:03:52 #topic status update 14:04:05 thanks ajo 14:04:11 thank you ajo 14:04:42 added the rfe for the dscp markings…https://bugs.launchpad.net/neutron/+bug/1468353 …if we doing status updates 14:04:43 Launchpad bug 1468353 in neutron "QoS DSCP marking rule support" [Undecided,In progress] - Assigned to Victor Howard (victor-r-howard) 14:04:52 er yeah 14:04:52 ajo: can you share the data model commit 14:05:00 thanks vhoward :-) 14:05:02 moshele, yes: 14:05:05 np 14:05:10 https://review.openstack.org/195050 14:05:16 #link https://review.openstack.org/195050 datamodel 14:05:26 not sure if link accepts extra comments ;) 14:05:40 in general: 14:05:43 #link https://review.openstack.org/#/q/topic:neutron-qos,n,z 14:06:18 #link https://bugs.launchpad.net/neutron/+bug/1468353 14:06:19 Launchpad bug 1468353 in neutron "QoS DSCP marking rule support" [Undecided,In progress] - Assigned to Victor Howard (victor-r-howard) 14:07:11 I did a split of the monolitic patch with the API extension, svc plugin and the AFTER_READ callbacks 14:07:29 so we can split work now/during sprint 14:07:56 How to join remotely 14:08:12 and ihrachyshka has been working on the design to let the plugins/ml2 declare the supported rules 14:08:37 vikram, let's talk about it when we move topics, is that ok? :) 14:08:43 ok 14:08:43 I wanted to rise that specific discussion :) 14:09:01 ;) 14:09:27 moshele, is also WIP on the agent extension, and he's breaking up in smaller patches too: https://review.openstack.org/#/c/189723/ 14:09:52 moshele, any comment about it? :) 14:09:53 yes it will be 3 commits: agent extension mgr , QosAgent , SR-IOV Agent driver 14:10:10 ajo, I wanted to add something for that in qos plugin but it seems that I cannot do it without rebasing your patches, so postponed service plugin side 14:10:36 moshele, cool, looking fwd to see it split, then I'll be of more help reviewing it 14:10:39 ihrachyshka feel free to rebase/fiddle around the patches, or we can just sync in the sprint :) 14:10:59 ihrachyshka & moshele , thank you to for working on this 14:11:02 to->too 14:11:07 ':D 14:11:07 ajo, nah, I don't think rebasing helps too much. also, on relevant note, we need to rebase branch anyway. otherwise gate fails. 14:11:21 ihrachyshka, correct, I have checked with infra how to do it: 14:11:50 #link http://docs.openstack.org/infra/manual/drivers.html#feature-branches 14:12:10 So I'd try it soon (tomorrow I guess) 14:12:30 I've been investigating on the generic RPC part, and I've almost have a new patchset. 14:12:46 I've been playing with messaging, fanout queues, and oslo versioned objects 14:13:13 ajo: is there some POC code you can share? 14:13:15 ajo, for that new RPC approach, I kindly suggest to raise it in wider community 14:13:17 I believe we really can do it as I was proposing, and thanks for the good amount of comments / suggestions. 14:13:43 ajo, it's too much of a change in paradigm to do it in qos tenet 14:13:48 ihrachyshka, ack, I will raise it on the list for higher audience 14:14:00 ihrachyshka, or move the devref to master 14:14:19 ihrachyshka, does that sound ok? :) 14:14:19 ajo, both to my taste ;) 14:14:25 ack :) 14:14:40 I want people from oslo and nova to chime in on upgrade scenarios 14:14:48 I'm trying to loop in the people with experience in that stuff, but I guess ML will work better :) 14:15:26 ihrachyshka, as for versioned objects, I don't want an oslo/multiproject to happen first, we could try the approach ourselves, and then export if that works for all 14:15:38 may be oslo_versionedobjects_pubsub :P 14:15:44 ajo, we'll need to look into o.vo in L anyway. 14:16:06 ihrachyshka, yes, I'm looking into it already, and we can support a mixed environent 14:16:11 ajo, yeah, that's why I want oslo guys there. it seems like a generic approach that may fit oslo_messaging or whatelse 14:16:19 what you want published... you need to add a VO layer (with this specific approach) 14:16:33 oslo_remotecallbacks :P 14:16:42 I'm too bad for names 14:16:50 oslo_remotee 14:16:51 :) 14:17:12 but again, in my own experience, when you try to do something from-oslo first, needs more time, than if you do it in-project first, and then export 14:17:36 we cannot risk waiting another cycle to get QoS for those details, we could export, refine, and readopt later 14:17:45 but their feedback would be very valuable 14:17:47 ajo, I agree. we can start in neutron, but design wise, we need more eyes 14:17:54 ajo, o.vo started like nova thingy 14:18:18 ihrachyshka, if they had tried to discuss that U/S with all, they'd still be bike shedding 14:18:19 :-) 14:18:45 I don't feel like making final call on upgrade and rpc versioning 14:18:51 but insted, they show it was a good approach by making it work 14:18:58 ihrachyshka, wait for my next PS ;) 14:19:18 I know, more -1's ... but I believe we're heading into a good direction 14:19:46 let's keep the discussion on the review :) 14:20:06 #link https://review.openstack.org/190635 14:20:07 ok 14:20:20 #topic mid cycle sprint 14:20:43 I plan to send a ML message to raise awareness and decide how to do remote participation 14:20:58 last meeting we were talking about doing video conference at the end of each day, and keeping an etherpad/log 14:21:09 I've been advised that probably IRC meetings work best 14:21:22 so we could held them in #openstack-neutron or a separate channel if that becomes too noisy 14:21:51 vikram: what time of day (UTC) do you start/end working in your timezone? 14:21:55 vhoward, and you? 14:22:02 sc68cal ? :) 14:22:12 We are 5:30 ahead of UTC 14:22:32 I'm keeping US EST hours 14:22:56 so UTC -4 14:23:02 i'm on EST as well 14:23:14 :D we are all around the globe 14:23:21 start=5:00hrs and end=19:00hrs 14:23:44 one plan was to have an afternoon meeting every afternoon (14:00 UTC) 14:23:54 Tue/Wed/Thu 14:23:57 works good for me 14:24:18 that sounds reasonable 14:24:20 vikram, if that's not too late for you, and sc68cal /vhoward can live with it for a few days too, that'd be good, I guess 14:24:30 sounds good 14:24:33 I am okay ajo 14:24:41 we could use #openstack-neutron with fallback to #openstack-neutron-qos 14:24:52 thanks vikram , sc68cal , vhoward :) 14:25:37 I will put the details in a message to the mailing list. 14:25:44 and arrange an etherpad where we could keep a log of work 14:25:52 +1 14:26:07 ajo, thanks for driving all bureaucracy. it's tough. 14:26:22 ihrachyshka: it's just the boring part :) 14:26:36 but most importatnt:) 14:26:45 yes thank you 14:26:45 said that, with coordination, please know I'm ok with anybody taking over any of my patches to handle comments, etc... 14:27:05 we may sync via patch comments / irc when doing such things :) 14:27:08 I think we can take up the extension patches 14:27:48 vikram, there's interesting stuff to discover in there about how to configure the URIs of the resources as we want 14:27:56 we will have to coordinate on where you need help/the june3rd etherpad seems almost full 14:27:59 the default helpers don't allow that, so I guess we need to construct controllers, etc manually 14:28:18 i like the idea of just fixing commented patchsets 14:28:44 ajo: we can resolve open issues together :) 14:28:49 may be we can use an etherpad as a locking mechanism to say when somebody is editing a patch. 14:28:57 +1 14:28:59 i like that 14:29:16 like.. keeping a list of patches, and who's editing... when you submit your patchset, and finish editing, you can send it back... 14:29:17 +1 14:29:19 to "free" 14:29:27 or if you have to stop working on it... 14:29:31 the idea is not to block others 14:29:36 nice 14:29:48 this is very collaborative, so I guess it's ok for very obvious things, big changes in design would need discussion 14:30:10 with the author/other people, we can use the daily meetings for that :) 14:30:27 over IRC? 14:30:47 vikram, irc meetings should be good for discussion... 14:31:06 or the etherpad or review comments themselves... 14:31:10 how abt daily meetings 14:31:24 vikram, what do you mean? 14:31:41 with the author/other people, we can use the daily meetings for that :) 14:31:44 i didn't get it fully 14:32:23 vikram, I mean, that taking over others patch is ok when we're following a colletive plan, but for introducing big design changes we need to ask via review comments, or in the daily 14:00 UTC meeting 14:32:43 ok got it .. bingo 14:32:57 ':D sorry, I'm not very good at explaining myself sometimes 14:33:08 ok, any questions about the sprint? 14:33:23 i am slow to understand either :) 14:33:33 nah :) 14:33:51 When you will share the etherpad? 14:34:08 I'll send a message to ML with you all on CC 14:34:12 probably during tomorrow morning 14:34:21 ok great 14:34:37 #topic other stuff 14:34:46 sc68cal: ping, we may need your help to setup the experimental job 14:34:57 \quit 14:35:30 sc68cal, if you couldn't do it before the sprint, any pointers would be welcome. 14:36:13 ajo: Are there patches landed in the qos branch yet? 14:36:31 making an experimental job with no code to exercise is probably not wise 14:36:33 sc68cal, nope, but we could use the experimental job to test those patches at least 14:37:03 sc68cal, can't you trigger the test over an specific patch? 14:37:08 may be I'm trying to go too fast? :) 14:37:38 ajo, you mean, a job that hardcodes some HEAD that is not master? 14:37:38 I'll chat with people at the midcycle and see if they have any suggestions 14:38:00 s/master/feature branch HEAD 14:38:07 ihrachyshka, we just need something that triggers the neutron full test with the service configured in /etc/neutron/neutron.conf 14:38:37 sc68cal, I guess that's all we need, right ^ ? 14:38:59 hmm, and same for api tests 14:39:09 ajo, yeah, but service is not committed, so you need another HEDA 14:39:11 *HEAD 14:39:26 "head" isn't the specific patch you're testing? 14:39:55 you go to patch in the chain... and trigger the job... the job installs the service, and runs it.. 14:40:03 I'll look into what we can do to test the qos feature branch - I know there is a BRANCH_OVERRIDE that devstack-gate has 14:40:33 thanks sc68cal 14:41:05 so far we will be having unit tests, functional tests, 14:41:08 it's more likely that we'll get something going after the qos sprint next week, when we have code in the branch 14:41:22 but we will need some arrangement for api-tests, I guess 14:41:37 ok 14:41:44 so quick question, how are you implementing bandwidth api mods, we'd like to model that for dscp…if its part of the main qos patch we can help add it, sorry if its a dumb question 14:41:52 let's run those locally during the sprint then, and sc68cal , ask if you can, at least to provide some pointers if we need to do it 14:41:54 can take that outside meeting btw 14:42:10 vhoward, no dumb question, wait 14:42:44 #link http://specs.openstack.org/openstack/neutron-specs/specs/liberty/qos-api-extension.html 14:42:48 look for "Create Rule Request" 14:42:50 is that what you mean? 14:43:00 or do you mean the actual code supporting that? 14:43:17 the former doesn't exist yet in full... 14:43:21 it works, but on a different URI 14:44:29 was just trying to see if i had to include the api portion within my spec, i'll read up more but looks like we just include our json then the client calls to implement? have to dig a bit i think 14:44:29 * sc68cal has to hop in car to go to the midcycle 14:45:06 vhoward, may be an exaple of API calls creating dscp rules would be good, not sure if that's needed for the new RFE anyway 14:45:10 sc68cal, enjoy!! ;D 14:45:36 vikram remainded me that we need to gather feedback on this for the future: https://etherpad.openstack.org/p/flow-classifier 14:45:47 https://review.openstack.org/#/c/190463/ 14:45:56 please review if you have spare time 14:46:01 k, thanks ajo 14:46:18 thanks ajo 14:46:34 we have the discussion about this over SFC IRC 14:46:41 :-) 14:46:44 fun ahead! ;) 14:46:45 if someone interested please join :) 14:47:09 vikram, what's the time of that meeting and what's the expanded version of "SFC" ? 14:47:25 I tried to join once, but I couldn't make it btw 14:47:45 SFC: Service Function chaining 14:47:50 true, that's it ;D 14:48:14 http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting 14:48:41 :) 14:48:49 ok, any question or any topic that I missed? 14:48:56 or shall we #endmeeting ? 14:49:56 ok, thanks everybody for joining once again :) 14:50:02 bye 14:50:02 keep up the good work! ;) 14:50:08 you too :) 14:50:29 bye 14:50:30 #endmeeting