15:04:01 #startmeeting neutron_northbound 15:04:01 Meeting started Wed Jun 1 15:04:01 2016 UTC. The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html. 15:04:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:04:01 The meeting name has been set to 'neutron_northbound' 15:04:23 #chair mkolesni oshvartz asomya 15:04:23 Current chairs: asomya mkolesni oshvartz yamahata 15:04:32 #topic agenda bashing and roll call 15:04:35 #info yamahata 15:04:50 sorry for my absence the past two weeks. 15:05:05 no problem 15:05:17 Do we have any adgenda in addition to usual patch/bug review? 15:05:28 I have two announcement today. 15:05:34 we can talk about the spec process 15:05:45 and perhaps about journal recovery if we have time 15:05:53 #info agenda spec process 15:06:15 #info agenda journal recovery if we have time 15:06:26 any other topics? 15:07:14 seems nothing else. 15:07:18 #topic Announcements 15:07:26 https://review.openstack.org/#/c/312199/12/specs/newton/neutron-stadium.rst 15:07:31 we have so AIs there 15:07:37 but we can keep it to other meeting 15:07:41 Yes, that's exactly I'd like to share it. 15:07:56 ok :) 15:08:33 In order to stay under neutron stadium, networking-odl has to fulfill some issues. 15:09:35 The line 303 15:09:39 We have to 15:09:51 * adopt neutron-api, and neutron-lib; 15:09:59 * complete docs, end-to-end testing, and demonstrate ability to upgrade; 15:10:30 Per code wise, I suppose we can address it. 15:10:45 For documentation, we don't have anyone assigned to it explicitly. 15:10:56 right now 15:11:09 we should probably turn these into bugs or rfes 15:11:23 concrete tasks 15:11:39 #action yamahata everyone need to break down stadium items into concrete tasks and have it assigned 15:11:55 bugs/rfes sounds good idea! 15:12:24 so that we have a good way to track it 15:12:53 i can document the journal & maintenance infra for example so i'll add a bug for that 15:13:22 cool 15:13:48 #action mkolesni file a bug for document the journal & maintenance infra for example 15:14:46 If we have any questions/issues on neutron-stadium.rst, we have to raise it right now. 15:14:51 it would be merged soon. 15:15:31 I have another issue to share 15:15:51 In ODL side, big code change/re-architect is planned/happening. 15:16:20 i.e. In ODL netvirt project, the code base would be changed from the existing one to VPNService 15:16:37 how does that affect us? 15:16:55 devstack may need update. 15:17:19 I'm asking Erricson guys to update it. But I'm not sure they do in timely manner. 15:17:38 We'd like to start to test it proactively. 15:17:53 do they have someone working on ODL's neutron or networking-odl project? 15:17:55 It would also causes regression/QA issues 15:18:14 Vithal and vivek are familiar with networking-odl. 15:18:32 They are also working on ODL side. I don't know their priorities. 15:18:56 if they dont have anyone dedicated then it probably not in their priority list 15:19:02 ODL behaviour would be changed radically. 15:19:15 Can we create a list of tasks for it > 15:19:16 ? 15:19:21 Sure. 15:19:44 #action yamahata/everyone to create tasks to track vpnservice code base issue 15:20:29 In ODL netvirt project, they are having code walkthrought etc recently. 15:20:50 They've recorded the session. So you man be interested in it. 15:21:12 sure, can you send the link for it 15:21:39 https://lists.opendaylight.org/pipermail/ovsdb-dev/2016-May/thread.html 15:21:52 The details are announce at the mailing list 15:22:30 That's all from me. 15:22:35 any other announcement? 15:22:44 nothing from my side 15:23:15 #topic action items from last meeting 15:23:39 The spec for journal recovery was already filed. 15:23:59 The next topic is spec process 15:24:06 im working on a detailed spec 15:24:08 #topic spec process 15:24:18 so its going along with the next topic 15:24:39 #link https://blueprints.launchpad.net/networking-odl 15:25:06 For now we have several blueprints and I had assigned priority based on my personal opinion 15:25:32 For now the goal is to track our activity in lightweight way. 15:25:48 so i see a spec for qos driver 15:26:07 #link https://review.openstack.org/314221 Add Spec for QoS driver 15:27:08 Yea 15:27:42 As the management process, do we have any issues? or any request to change the process? 15:28:11 When we have new blueprint, we can discuss it in this meeting and approve it/assign priority. 15:28:55 any thoughts/comments? 15:28:56 i think some things need more than blueprint 15:29:10 but otoh a big spec like neutron is too much 15:29:49 for example for journal recovery the bp is shallow 15:29:54 no design details 15:30:23 so im also writing a spec for review 15:30:57 Got it. Do we want formal process? or just discuss case-by-case basis? 15:31:06 i think what we probably need is a spec template, perhaps the one from neutron could do but we should probably simplify it 15:31:16 i also see in tree spec for sfc 15:32:12 if we use specs for review we should also put them somewhere 15:32:50 btw, if we continue in the stadium the stadium doc specifies that specs should be in neutron-specs if im not mistaken 15:32:57 or use rfe process 15:33:47 for the stadium, the basic principle is to resemble neutron process, but in lighter way. 15:34:57 Do we want spec repo? or is it okay to store them in doc directory? 15:35:07 For now we are using doc/ dir. 15:35:19 i think for now doc/source/specs 15:35:31 since its not quite user facing documentation 15:35:39 so probably no reason to mix them 15:35:47 mkolesni: sounds reasonable 15:36:49 if it's okay, I'll send a patch to create the dir and move the existing under it. 15:37:06 #action yamahata upload a patch for doc/source/specs dir 15:37:22 any other thoughts/comments? 15:37:39 sure 15:37:57 i will send a patch for a template? 15:38:16 and we can decide per blueprint if we want a spec reviewed or not 15:38:23 cool 15:38:31 #action mkolesni send a patch for a template 15:39:59 anything else? 15:40:17 nothing about this 15:40:37 move on 15:40:53 #topic patches/bugs 15:41:28 any patches/bugs to raise? 15:41:35 mkolesni: do you have some? 15:41:42 yes 15:42:00 #link https://review.openstack.org/312033 Complete port details by journal instead of mech driver 15:42:14 this can probably be merged 15:42:36 asomya: rcurran do you have any issues with the patch? 15:43:20 yikes blinking icon :-) ... sorry busy w/ other projects 15:43:31 just reviewed full sync - looks good 15:43:45 and this requires the port detail change ... i'll +1 15:43:58 Can you please take a look at 312033? After your's review, we would merge it. 15:44:03 no issues from my end 15:44:34 asomya: rcurran thanks 15:44:51 i saw rcurran's comments on the full sync patch, will try to address them asap 15:45:01 Now I merged 321594 Updated from global requirements 15:45:01 #link https://review.openstack.org/321504 Refactor SG callbacks 15:45:43 #action mkolesni respin 307218 ODL v2: Full sync resources 15:46:02 #action everyone review https://review.openstack.org/321504 Refactor SG callbacks 15:47:02 #link https://review.openstack.org/#/c/308031/ 15:47:03 pseudo-agentdb-binding 15:47:24 I suppose maintenance thread issue needs to be resolved. 15:47:49 mohammed will address it. 15:48:14 any other patches/bugs? 15:48:16 i think it doesnt make sense to introduce those changes 15:48:28 i dont know if you guys are in agreement or not 15:48:40 perhaps we should discuss here and come to a conclusion? 15:49:08 Do we have mohammed? 15:49:30 personally I'm okay with either way. 15:50:07 the change makes the simple logic more complicated thus making it more bug prone IMHO 15:50:09 So you mkolesni has opinion, we can go for your call. 15:50:19 ok :) 15:50:47 just trying to voice my thoughts on that 15:51:10 essentially we should strive for as much simplicity as possible 15:51:25 since complexity makes it harder to spot bugs 15:51:57 thats why i do some refactors here and there to reduce the complexity 15:53:56 agreed that's KISS principle 15:54:40 cool 15:54:53 we covered most patches. 15:54:58 next topic 15:55:10 #topic ODL neutorn northbound 15:55:22 #link https://lists.opendaylight.org/pipermail/neutron-dev/2016-May/000782.html networking-odl driver for sfc yang models 15:55:39 Anil has raised an issue on ODL northbound API. 15:55:56 So far ODL neutron northbound REST API is hand written for networking-odl. 15:56:09 He wants to use restconf with yangmodel directly. 15:56:27 To be honest, I haven't understand its implication. 15:56:40 this means we need to adapt the client code in networking-odl? 15:56:53 Maybe, maybe not. 15:57:08 thats what i understood from the email 15:57:26 we need to understand those issues before deciding. 15:58:32 Or postpone the dicusion to the next cycle and stay in the current way. 15:58:43 for this cycle. 15:59:00 is the networking-odl-sfc going to use the journal mechanic? 15:59:23 Yes. Our principle is to require v2 driver, isn't it? 15:59:33 yeah just making sure 15:59:54 so from what i understood it's about the client we use 16:00:06 would it call "neutron" like APIs or direct ODL ones 16:00:28 Yes. 16:00:31 i dont know whats the pros and cons of each approach 16:00:45 so perhaps Anil can elaborate on that? 16:01:17 Rigth, Anil should discuss about it because he wants to drive it. 16:01:40 Otherwise, I'd like to postpone it to the next cycle. 16:01:50 im fine with that 16:02:12 Eventually we should evaluate those issue. But I don't think we have another engineering resource for this cycle. 16:02:54 okay, we're over running. 16:03:03 so please voice on the mailing list. 16:03:19 next topic 16:03:22 #topic boron planning 16:03:30 I reported M3 status. 16:03:43 #topic open mike 16:03:52 anything else to discuss today? 16:04:06 nothing from my side 16:04:15 i think we will skip bluejeans? 16:04:23 personally i have to go 16:04:30 Do we have urgent/complex issue? 16:04:40 asomya: rcurran ? 16:04:51 nothing from me 16:04:54 none from me, we discussed partial sync in bluejeans last week 16:04:57 Oh, then let's skip it today. 16:05:07 Thank you everyone 16:05:17 thanks Isaku & everyone 16:05:18 #topic cookies 16:05:23 #endmeeting