16:03:05 #startmeeting neutron_northbound 16:03:05 Meeting started Fri Jan 29 16:03:05 2016 UTC. The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html. 16:03:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:05 The meeting name has been set to 'neutron_northbound' 16:03:12 #topic agenda bashing and roll call 16:03:18 #info yamahata 16:03:37 #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings#Agenda_for_Next_Meeting_.281.2F29.2C_2016.29 meeting agenda 16:03:55 is there any agenda to add? 16:05:26 seems nothing. move on. 16:05:28 #topic Announcements 16:06:01 opendaylight minisummit at OSN will be held 16:06:08 It's CFP is also open 16:06:24 #link https://lists.opendaylight.org/pipermail/discuss/2016-January/006134.html CFP for ONS OpenDaylight Mini Summit 16:06:41 opendaylight summit is also announced 16:06:55 #link http://events.linuxfoundation.org/events/opendaylight-summit opendaylight summit 16:07:39 lastly I can't chair next week. Feb 5. If anyone else is willing to chair, it would be skipped. 16:07:46 anything else to announce? 16:09:06 #topic action items from last meeting 16:09:33 For boron planning, I announced some links at odl neutron dev mailing list 16:09:45 #link https://wiki.opendaylight.org/view/NeutronNorthbound:FutureReleaseWishList 16:10:02 #link https://docs.google.com/spreadsheets/d/1b5JuGWwYISno-mcb92SC3_1bwncfo4ToB8b8480D15Q/edit?pref=2&pli=1#gid=0 feature and resource assignment 16:10:13 I created this google-sheet mimicking ovsdb planning. 16:10:52 But I'm not sure we need such formal assignment because our engineering resource is small and scope is smaller. 16:11:42 Maybe to track progress, trello board may be better. But I haven't decided yet. 16:12:06 john_a_joyce: reviewed the patch. 16:12:16 it is for odl or include neutorn? 16:12:23 #link https://review.openstack.org/#/c/215612/ 16:12:23 Enable vhost-user ports on supported platforms. 16:12:34 it's networking-odl. 16:12:46 yamahata: thanks 16:12:49 john_a_joyce: are you fine with the patch? 16:13:13 in order to make port-binding flexible, the follow up patch is coming 16:13:22 #link https://review.openstack.org/#/c/273390/ 16:13:22 Configure valid VIF types. 16:13:24 yes i reviewed that - i find it acceptable 16:13:37 If you're fine, I'm going to merge it. 16:13:47 Okay, then I'll merge it. 16:14:12 done. 16:14:26 yes i am fine 16:15:36 For boron planning Isaku and vithar have started the discussion. 16:15:53 it will be held on here, wiki page(wishlist page) and mailing list. 16:16:33 okay, all action items are done. 16:16:39 #topic patch reviews 16:16:50 I had one patch review item and it's done right now. 16:17:11 any other review for attention? 16:18:00 #topic bug 16:18:13 any bug needing care? 16:19:16 okay move on 16:19:21 #topic ML2 ODL driver rewrite 16:19:33 any raises? 16:19:41 I suppose patch review is on-going 16:20:18 yes, thanks for the comments 16:20:55 rcurran: I have question. You create one more thread for sync. Are you seeing difference? 16:21:12 I understand we'd like to make different service isolated from each services. 16:21:25 difference in what way? 16:21:35 e.g. L3 from L2 16:21:42 we know we have to support multiple journal threads to support HA 16:21:55 Can you elaborate on it? 16:22:21 in HA there will be as many threads as there are neutron controller deployments 16:22:49 yes, many threads in neutron servers. 16:23:59 yamahata: do you mean we can use the same thread ? 16:24:20 yamahata: to deal with L2 and L3 16:24:48 yalei: Yes. But we can have thread pool to handle journal db table. 16:25:08 rcurran's patch specifically uses two threads. 16:25:51 So I'm wondering if he has special reason to have _two_ thread instead of thread pool. 16:26:13 Or single thread is okay. 16:26:24 as written now it uses one thread/neutron-server process. i can eliminate the L3 call to start a thread but the overall design must be able to support multiple journal threads 16:26:42 in HA we don't have much of a choice 16:27:36 rcurran: I see. what kind of problem do you want solve? 16:27:53 e.g. request piling up in journal? 16:27:57 the case where two or more journal threads are running 16:28:07 or better isolation resource. e.g. L3 from L2 16:28:29 is there some special reason to isolation? 16:29:11 i don't think we should separate the l3/l2 processing. odl controller doesn't care. neutron separatation is why l3/l2 is processed differently today 16:29:25 ml2 core_plugin vs. l3 service_plugin 16:30:29 does the two kind of threads do the same? 16:30:37 yalei, no 16:30:49 I see 16:31:21 a journal thread doesn't distinguish that it's processing, just that the rows are processed in the correct order (dependency checking) 16:31:29 that -> what 16:32:02 i did think to do that at one point, but see the payoff 16:32:08 yes, that's what I mean 16:32:13 but didn't see the payoff 16:32:31 did or didn't? 16:32:46 didn't - why seperate l2 and l3 16:33:14 let me try again :-) ... i did at one point think to seperate ... but didn't see any payoff 16:33:25 Got it. 16:33:36 from odl controller perspective .. it just cares about the neutron events 16:33:54 So for now you have two threads, but for future, you'd like to switch thread pool. Correct? 16:34:56 At least it should be investigated. 16:34:58 ? 16:35:12 regarding number of threads, asomya and i are still looking into some changes ... but a requirement is that we *have* to suport two or more journal threads to support HA 16:35:55 so currently having two is actually good since it allows us to test (without having an HA environment) 16:35:56 Okay. Can you please elaborate the behind reasoning for the requirement? 16:36:37 What led you to play with thread? 16:36:38 i don't understand. in HA are you seeing a design w/ only one thread? 16:37:26 what's the difference between the thread pool and two explicit thread? 16:37:38 No. I think we need multiple thread at some point. 16:38:25 In L3 plugin code, can you please some comment to explain the situation? 16:38:54 Otherwise, I thought there is a strong reason to use _two_ thread. 16:39:24 Maybe TODO or something 16:39:44 TODO stating that the call from L3 is starting 2nd thread? 16:40:10 Yes. e.g. future direction is to investigate about the number of threads. 16:40:36 ok 16:41:26 any other review issues? 16:42:19 does the v2 driver support the full sync? 16:42:39 yalei: I haven't started it yet. 16:42:54 yamahata: I want to investigate it. 16:43:00 yalei: cool! 16:43:15 give it a shot! 16:43:32 yamahata: :) 16:43:46 anything else? 16:44:27 #topic OpenStack release support 16:44:39 no update so far. 16:44:52 #topic Beryllium release preparation and Boron planning 16:45:11 I've started discussion with other projects. 16:45:17 We can continue. 16:45:28 #topic Open Mike 16:45:32 any topics? 16:46:15 I raised a bug earlier today that I'd like to discuss: https://bugs.opendaylight.org/show_bug.cgi?id=5137 16:47:02 it is related to 4810, fixing model definitions. 16:47:05 Oh, extraroutes. 16:47:46 I was testing to see if it is supported so could use in vpnservice or not. 16:48:11 routes are defined as type string when should be host-routes. 16:48:29 4810 seems wrong number. 16:48:40 vthapar: do you need it for Beryllium? 16:49:32 yamahata: I think I do. 16:50:16 I was testing adding multiple nexthops with same prefix, which isn't needed in Be. but found that basic functionality isn't working 16:51:19 also, it showed that we need to strengthen our test cases. they seem to be just for coverage, we're not doing proper validation. 16:52:00 Do you mean test in openstack side? tempest? or ODL ci? 16:52:33 I meant our ITs. 16:52:55 unless you believe these are taken care of in ODL CI, or tempest. 16:54:03 we just test that crud succeeds, shouldn't we also test that all the data we created/udpated is reflected correctly in mdsal? 16:56:05 Right, the current test doesn't check its actual value. 16:56:17 This bug is a blocker for vpnservice? 16:56:48 do you have (WIP) patches? or need help? 16:56:53 not blocker, but impacts a use case we'd like to support. 16:57:04 I am working on patch and wanted some inputs on that. 16:57:21 we curently have NeutronSubnet_HostRoutes class which serves same purpose. 16:57:52 so what fix would be preferred, make a generic Neutron_HostRoutes class and use for routers and subnets, or create a new NeutronRouter_Routes class? 16:58:37 both have destination and next-hop fields. 16:58:38 The right direction is to support extraroute extension cleanly. 16:59:07 But for Beryllium, code s already freezed. 16:59:42 If NeutronSubnet_HostRoutes works for you (with minimul code change), it might be better. 17:00:18 yeah, that could work, will have to check the yang for l3 though, that might still need change. 17:00:46 will get back once I have a patch ready and can discuss this in gerrit. 17:00:52 Yeah, discussion based on actual patch will be more productive. 17:01:19 Don't hesitate to ping me 17:01:30 sure will. 17:01:47 any other topics? 17:01:49 and what about improving ITs? will take it up in Boron? 17:02:23 it's surely the item for Boron. We should raise it. 17:02:30 it would be a good low-hanging fruit for new folks. 17:02:51 add it to wishlist or covered by Sonar topics in there? 17:03:19 Please add it to wishlist to track it. 17:03:25 will do. 17:04:02 anything else? 17:04:14 * yamahata running over time... 17:04:25 going once 17:05:03 going twice 17:05:13 The next week the meeting will be skipped. 17:05:34 thank you everyone! 17:05:41 #topic cookies 17:05:42 yamahata: thanks 17:05:46 #endmeeting