18:02:04 #startmeeting networking_l2gw 18:02:05 Meeting started Mon Feb 2 18:02:04 2015 UTC and is due to finish in 60 minutes. The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:08 The meeting name has been set to 'networking_l2gw' 18:02:31 #topic Agenda: 18:02:36 https://wiki.openstack.org/wiki/Meetings/L2Gateway 18:03:19 #topic: Announcements: 18:03:41 We usually use this topic to give high level status of the project. 18:03:51 armax: is not here today 18:04:22 marutik: I noticed we have a lot of code merged - do you want to give a high level update? 18:04:30 Yes 18:04:47 We have started posting patchsets for both the plugin side and the agent side 18:05:43 The main patch set for plugin for REST APIs is under review, that is, https://review.openstack.org/#/c/144097/ 18:06:05 Hopefully it will get merged soon 18:06:56 I am amzed at the progress that you guys have made within such a short period of time 18:06:59 Agent side patch set https://review.openstack.org/#/c/145781/, once it gets merged, we will have very less number of patchsets remaining for the agent. 18:07:27 CI for L2 gateway is in good progress. Alok can also update on the same. 18:07:41 Thanks Sukhdev. 18:07:44 We have infrastructure ready for CI 18:08:26 Alokmaurya: when will CI start to vote? 18:08:32 Infra can not listen for triggers from neutron and ... it deploys new devstack 18:09:06 yo 18:09:07 As of now service account is enabled ...hopefully we can enable voting soon 18:09:37 Alokmaurya: cool - that is good news 18:09:40 currently plan is to start testing plugin /REST APIs 18:10:16 we are having some issue creating stack once we enable l2gateway plugin 18:11:15 once new patch for plugin is submitted ...hopefully issue will get resolved 18:11:32 Alokmaurya: can you elaborate on the issue that you are hitting? Devstack fails or neutron fails to start? 18:11:46 neutron fails to start 18:12:12 Ah ha.. I think then the patch would help 18:12:33 looks like plgin is using rpc classes whic has been removed from /neutron/common/rpc.py 18:12:52 Alokmaurya: are you enabling other service plugins as well ? 18:13:23 l2gw and l3 plugin 18:13:43 Yes, that makes sense 18:14:38 there have been effort going on to refactor API/rpc - perhaps that is causing the issue 18:14:55 hopefully when the patches merge, this should be resolved 18:15:47 We will sort this out tomorrow after looking at other service plugins. 18:15:47 Anything else on the high level update? 18:16:30 Nothing from my side 18:16:59 #topic: Patches under review - 18:17:07 #link: https://review.openstack.org/#/q/status:open+project:stackforge/networking-l2gw,n,z 18:17:24 marutik: already touched on couple 18:17:45 I looked at the pathes - things are looking very good 18:18:05 Everybody - please review them and provide feedback 18:18:12 Selva will hopefully submit another patch set for https://review.openstack.org/#/c/144097/ and then we are good to go with REST APIs. 18:18:18 tomorrow 18:18:58 Yes Iam currently working on enhancing test cases and I will update the patch shortly 18:19:07 marutik: How is the testing effort going? 18:19:32 Alok and Ashish are doing excellent job of automating the testing 18:19:47 soon i will writting more tests as per the rest api spec 18:20:18 I saw the patch on UTs and posted comments - looking good. 18:20:31 The only thing that is holding Ashish back is the place to commit the Tempest test cases . 18:20:41 #topic: Merged Patches 18:20:56 #link: https://review.openstack.org/#/q/status:merged+project:stackforge/networking-l2gw,n,z 18:21:34 Lots of patches have merged - which is great news - shows tremendous progress 18:21:43 I agree. 18:22:05 I am pulling in several folks from Arista to review these merged patches 18:22:14 That is great. 18:22:32 especially the OVDB schema for hardware vtep 18:23:06 Anybody has any questions on these patches? 18:23:18 After entire agent code gets merged, it would be good if you could request your team to validate the merged patches with Arista switches. 18:23:38 marutik: that is the intent - 18:23:59 Thanks. 18:24:27 we have an implementation - hence, want to make sure that the OVSDB schema is very similar/same - so that it can easily be integrated 18:24:46 Regarding to ovsdb and its schema, won't we use ovs python binding or will we implement ourselves? 18:25:23 I understand ovsdb is not complex, so it's feasible to implement our own version. 18:25:39 but I think it's worthwhile for discussion. 18:25:53 yamahata: correct - if you are implementing from scratch 18:26:05 In my next review/patch set, I am going to post new code for writing/reading from OVSDB hardware_vtep schema 18:26:48 In short term, I'm fine with l2gw own implementation. 18:26:58 marutik: are you familiar with the OVSDB schema for hardware vtep as used by NSX? 18:27:01 But what's the long term direction? 18:27:55 The Schema shoudl be the one from OpenvSwitch's (likely 2.3 LTS) git repository 18:28:17 Sukhdev, yes we are familiar with how NSX is using it. but not sure whether we will be able to address all the use cases in this iteration. 18:28:49 yamahata: ideally, if we can use the schema which matches with existing implementations - it becomes lot easy for existing systems to adopt 18:29:41 for example, we have lots of code which we can leverage on the back-end if the schema is same as used by NSX 18:29:57 I agree. 18:30:15 okay. 18:30:31 I think, we can provide comments on the code that I am going to post in near future. 18:30:38 marutik: at least for hardware vtep - if we can align with the existing implementation - it will be a great win for wider community 18:30:53 marutik: You can answer this definitely.. My understanding is that the schema is what NSX-MH is using, but as you point out, this implementation does not implement all of the use cases that NSX-MH uses 18:30:58 I agree. 18:31:23 E.G. Service Node, BFD, etc.. 18:31:43 Yes, Scott 18:32:09 marutik: looking forward to your patch on this 18:32:23 Thanks Sukhdev 18:32:23 Anything else on the schema? 18:32:47 #topic: Functional Testing 18:33:04 We touched on this subject in the previous meeting a bit 18:33:19 we will need to beef this up 18:33:27 any volunteers? 18:34:03 * Sukhdev waiting :-) 18:35:03 I guess when we are in a position to pull these patches and start to test, we can come up with the test 18:35:29 i will be adding more functional tests in the positive and negative side based on the latest specs in tempest framework 18:35:52 ashishg: that would be great 18:36:13 with some patches which resolves current issues ... we should be able to start testing 18:36:13 #topic : Action item from previous week 18:36:24 #undo 18:36:25 Removing item from minutes: 18:37:11 Alokmaurya: in the current CI - you do not have any tests specific to L2GW, right? 18:37:48 we have API tests 18:38:04 i have local copies of those tests 18:38:08 we will incorporate the rest api tests in that infrastructure as a initial testing 18:38:39 ashishg: cool - thanks for clarification 18:38:51 anything else on testing? 18:39:12 #topic: Action Item from last week 18:39:33 ijw and I had an action item to come up with a wiki for this project 18:39:52 #link: https://wiki.openstack.org/wiki/Neutron/L2-GW 18:40:05 Did you guys have a change to look it over? 18:40:14 This is great 18:40:50 This is an initial cut - please review it and feel free to provide feedback 18:41:15 or better yet, please add any use case or any other content as you feel fit 18:42:06 I agree 18:42:06 Anything on the wiki? 18:42:49 #topic: Virtual Gateway Implementation 18:42:55 On the use cases - add them, correct them if they're wrong. Don't delete them just because the current implementation doesn't address them, though, because that doesn't invalidate them. 18:43:03 #undo 18:43:04 Removing item from minutes: 18:43:48 ijw: good point - we should mark on the use case that is not covered by this implementation 18:44:14 And, of course, add more ;) 18:44:24 They're just the ones I've heard about, I don't claim to know everything 18:44:30 I am always right, but that's a different matter ;) 18:44:49 ijw: ha ha you are funny!!! 18:45:31 anything else? 18:45:55 #topic: Virtual Gateway Implementation 18:46:11 We touched this last meeting as well 18:46:38 Our present implementation is HW device based - it will be good to extend it to virtual implementation 18:46:59 yamahata: ? 18:47:13 Sukhdev: hi. I'm interested. 18:47:20 yamahata: You had expressed interest in it 18:47:30 Both in reference implemetation(ovs agent) and ODl plugin. 18:47:39 Probably for L cycle. 18:47:53 yamahata: when you review the code, be sure that it is generic enough to cover virtual use cases as well 18:47:54 For Kilo. I:m not sure. 18:48:02 yamahata: understood 18:48:41 That's all from me. 18:48:52 cool thanks 18:48:53 In the context of this implementation, the SouthBound interface to the VTEP GW is OVSDB, so I assume the Virutal Gateway will be configured using OVSDB as well 18:49:22 smillward: does not have to be - but, could be 18:49:24 Yes, that's my understanding. 18:49:35 If the SB protocol is different (e.g. New RESTconf calls to ODL), then this would be a differerent implementation, right? 18:49:50 Sukhdev: Right. it doesn't have to be. 18:50:06 ODL supports ovsdb protocol too. 18:50:09 smillward: correct - there could be multiple impementation on the SB side 18:50:19 smillward: I think the question at the moment would be whether the model fits either a software implementation or the way you might choose to implement it in ODL 18:50:30 Got it, more at the API layer 18:50:40 smillward: correct 18:51:14 This API should support multiple SB implementations 18:51:18 Yes 18:51:24 My concern over the last model I saw is that the nomination of HW devices in calls is exactly the opposite of how physical networks are declared (in config). If I were to implement this in ODL I (personally, and it's a choice) wouldn't want to expose hardware details to Neutron. 18:51:33 The first implementation is for OVSDB as SB API 18:51:38 It's possible that the two parts of the interface should be independent of each other. 18:53:15 ijw: I do not think it is any different from present implementations - i.e. you define physical/provider networks in the config 18:53:29 and then use them/reference them in APIs 18:54:24 ijw: Moreover, some of the config knobs are optional - hence, can be ignored by some implementations 18:54:47 * Sukhdev time check - 6 min remaing 18:54:59 #topic Open Discussion 18:55:22 Folks, we have covered our agenda - anybody wants to discuss anything? 18:55:44 * Sukhdev waiting 18:56:22 Folks thanks for great discussion and your participation 18:56:34 thanks 18:56:34 We are done 18:56:37 Thanks 18:56:41 #endmeeting