16:05:17 #startmeeting networking_ml2 16:05:17 Meeting started Wed Dec 17 16:05:17 2014 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:05:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:05:20 The meeting name has been set to 'networking_ml2' 16:05:46 #link agenda https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_December_17.2C_2014 16:06:11 #topic Announcements 16:06:37 Sukhdev: do you want to chair today? 16:06:56 rkukura: Can you do it please? 16:07:02 no problem 16:07:12 rkukura: Sorry for being late 16:07:23 we were just starting the announcements 16:07:28 Kilo-1 is this week 16:07:54 #link content https://launchpad.net/neutron/+milestone/kilo-1 16:08:33 so the main “feature” is the split of advanced services into separate repos 16:08:45 I don’t see anything major related to ML2 16:09:30 please be on the lookout for any issues caused by the services split, and file bugs if needed 16:10:00 the mid-cycle meetup was last week, hence no ML2 meeting last week 16:10:07 when will the driver split be handled 16:10:23 #link etherpad https://etherpad.openstack.org/p/neutron-mid-cycle-sprint-dec-2014 16:10:36 #link report http://lists.openstack.org/pipermail/openstack-dev/2014-December/052715.html 16:10:59 rkukura: Sprint was very productive 16:11:07 Sukhdev: agreed 16:11:48 The main ML2 related work was on the plugin/driver decomposition, which we’ll discuss in the next topic 16:11:57 shivharis: over two releases 16:12:36 I was hoping to get better insight into how the core refactoring work would effect ML2, but don’t think they are far enough along on that yet 16:12:44 Sukhdev: Do you have anything to add? 16:13:16 this is fair enough 16:13:34 Any other announcements? 16:14:11 #topic ML2 Drivers Decomposition 16:14:37 Check out the pictures of the sprint in the etherpad 16:15:00 Both Sukhdev and I, along with armax and Dane from Cisco spent most of our time at the meetup on the decomposition 16:15:52 We started with armax’s spec, and worked out some of the details, particularly for ML2 drivers 16:16:18 I am starting to look into the split for the ucs manager mech driver 16:16:48 Any notes/minutes of the decomposition meetings 16:16:53 ? 16:17:18 We seemed to achieve consensus around an approach where drivers are made up of an in-tree integration layer and an out-of-tree library, with as much backend-specific logic as possible moved to the library. This lets vendors update it more quickly, and reduces the load on the reviewers. 16:17:19 rkukura: special interest regarding generic MDs split, like SR-IOV 16:17:43 shivharis: the spec was modified to reflect the understanding as well it is captured to some degree in the etherpad 16:18:41 Sukhdev: etherpad is sparse in describing 16:18:43 But it still allows the driver APIs to continue to evolve, fosters at least some refactoring and code sharing, and reviews of the integration layer can help ensure drivers can safely co-exist in heterogeneous deployments. 16:19:59 shivharis: it is by design :-) 16:20:02 So based on this agreement, Sukhdev got a good start on decompositing the Arista MD, and Dane and I worked together on figuring out how the Cisco Nexus MD could be decomposed (including the HPB support that isn’t merged yet). 16:20:20 rkukura: should SR-IOV MD be hosted in its own repository, or there should be some common repo for generic MDs (SR-IOV, LinuxBridge,...)? 16:20:27 Vendors, as always, can choose to keep their drivers entirely out of tree if they prefer 16:21:07 I think the same arguement would apply for type drivers too, I suppose 16:21:17 irenab: all MDs (except OVS) will follow this methodology 16:21:37 I think Irena is saying that some SR-IOV code is not vendor-specific. 16:21:40 irenab: I think the OVS and LB MDs are staying in-tree, at least for now. Since these just use agents-db, they don’t have much code that could be moved 16:22:12 rkukura: same is for SR-IOV 16:22:23 I’d think SR-IOV drivers could move some vendor-specific logic out-of-tree if that makes sense. 16:22:41 rkukura: There is no vendor specifc code there 16:23:03 Should have also mentioned that DB models and migrations can stay in-tree for now, avoiding the need for separate migration chains and db-manage tools. 16:23:09 rkukura: irenab's sr-iov mech driver does not have vendor specific code 16:23:22 their agent takes care of vendor specific functions 16:23:50 rkukura: about DB models, do the get and put functions also stay in tree? 16:24:23 sadasu: I think there is some flexiblity on exactly where the line is drawn for the DB access. 16:24:24 sadasu: we debated about the action functions for the DB models 16:25:07 Ideally, if they can be moved out, move them out - but, there is bit flexibility about it 16:25:33 We also looked at the Cisco APIC MD a bit - it already has most logic out-of-tree, but more could probably be removed from the tree. 16:26:08 We didn’t really discuss type drivers or extension drivers very much, but I think the same general approach should apply. 16:26:19 sadasu: The argument was made that if there is a bug in the action function, it does not make sense to get the core approval for it - vendor's should be able to fix it themselves 16:26:38 My guess is these typically would not have much code (if any) that would make sense to move out-of-tree. 16:27:59 rkukura: Any code change in tree requires cores approval, right? 16:28:08 My understanding is that drivers have a couple cycles to implement the decomposition, but nothing but bug fixes will likely get merged in kilo for drivers that haven’t at least done a first phase of decomposition. 16:28:24 Sukhdev, rkukura: so the general guideline seems to be, will this affect neutron core function and need core approval? 16:28:26 irenab: Yes, the in-tree code gets reviewed by cores. 16:28:35 if the answer is no, then it goes out of tree 16:29:09 sadasu: correct. 16:29:19 out-tree code is not reviewed by anyone except the vendor? 16:29:44 shivharis: that is the idea 16:29:53 sadasu: Another guideline is whether the code directly uses ML2 driver APIs - if so, it can/should stay in-tree. This facilitates evolving the driver APIs until they become more stable. 16:30:17 Anything else on the decomposition before we move onto BPs? 16:30:49 Should we plan to discuss this further next week after people have had a chance to think about how it impacts their drivers? 16:30:58 mestery and I working on a sample MD 16:31:30 #action add driver decomposition discussion item to next weeks agenda 16:31:38 Sukhdev: Is that the ODL driver mestery had started on? 16:31:45 mestery is ahead of me and has decomposed the ODL MD - this will be a good sample to look at 16:31:47 Sukhdev: when it will be ready? 16:31:52 rkukura: yes 16:32:18 #action all look at decomposing your drivers so we can discuss further next week 16:32:38 moshele: It almost ready - he was working out some issue with unit tests 16:32:54 I am little bit behind - will take me a week or so to complete 16:33:03 Both of these will act as samples 16:33:18 this should give you the idea about the decomposition boundaries 16:33:20 should also have mentioned that unit testing can get tricky with this, and probably involves more work than moving the driver code itself 16:33:39 rkukura: agreed 16:33:51 rkukura: exactly 16:34:24 I am having issues with unit tests as well - at the moment it is all broken :-) 16:34:24 also meant to mention that stackforge is available to host the backend-specific libraries 16:34:54 if the MD has an agent code should some of it (agent code ) be in the tree? 16:34:58 Sukhdev: Do you have the link to the info on getting stackforge repos setup? 16:35:16 yes, I - let me look 16:35:24 moshele: I’d think backend-specific agent code should be out-of-tree 16:35:50 #link http://docs.openstack.org/infra/manual/creators.html 16:36:02 This is where a modular agent would be nice - with vendor drivers integrated similarly to what we do in ML2 16:36:10 Sukhdev: thanks 16:36:24 Anything else on decomposition? 16:36:46 #topic BP List Consolidation 16:37:00 shivharis, manishg_: Do you have an update on this? 16:37:34 It is updated here : https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews 16:37:35 manishg_ and I sat down to cleanup/addon to the list 16:38:17 the list is still work in progress(WIP), is a starting poiunt for owners of BPs to update 16:38:22 wish I could have been there ;) 16:38:50 rkukura: for the drinking part, right? :-):-) 16:38:51 please take a look at it, see if we missed anything there 16:38:56 which columns do we need? Should we get rid of code/R1/R2/R3/R4/C1/C2/C3 etc. ? 16:39:06 I see quite a few driver specs in the list - should we move those to a separate section? 16:39:23 shivharis: please add this one: https://blueprints.launchpad.net/openstack/?searchtext=network-settings-support-vnic-type 16:39:24 manishg_: Yes, please clean it up 16:39:26 rukura: I not sure I understand the decision regarding SRIOV, it look like SRIOV MD generic for all vendor and can be in tree and the agent can move out why do you think? 16:39:35 agreed the drivers will move out of the list, we simply wanted to get everything in and then split it out 16:39:46 rkukura: yes, will move them out. 16:40:20 manishg_ anything else you want to add? 16:40:33 We have simply looked for drivers that have ML2 mentioned . Not all of them do! In which case, the authors may have to add it here. 16:40:37 irenab: will do. 16:40:49 shivharis: I’d suggest moving them to separate section - people may want to look at them even if they are not being reviewed/approved. 16:41:15 shivharis: do we need the 'merged' section? e.g. merged in Juno 16:41:27 rkukura: of course, they will be visisble 16:41:42 I believe the drivers team is still in the process of reviewing specs for kilo 16:42:12 Are there ML2 specs (other than vendor-specific) that aren’t approved yet that we want to try to get approved 16:42:15 rkukura: i dont think they are reviewing at all 16:42:23 rkukura: SAD deadline is gone 16:42:36 rkukura: please connfirm if they are really reviewing.. 16:42:44 rkukura: this one https://review.openstack.org/#/c/138753/ 16:42:49 My understanding from the neutron IRC meeting was that reviewing would continue this week 16:43:18 also, I think the way to keep this twiki up-to-date is that authors update the status. 16:43:21 otherwise it will become out of date quickly. 16:43:27 rkukura: kyle has been putting -2 with a note saying it is not needed 16:43:38 please take a look, this may be very valuable for SR_IOV use cases 16:43:51 irenab: Agreed 16:44:01 thanks! 16:44:09 anyways back to the list, anyone has questions? Also please look at the list and pay particular attention to your item 16:44:13 Port Security Extension driver https://review.openstack.org/#/c/99873/. It is there on the wiki. It has +1s but no core approvals yet 16:44:15 So if a spec doesn’t have a +2 or -2 yet, I think it is still in play 16:44:48 most m-drivers have -2 16:45:06 mestery, salv-orlando: Are spec reviews continueing this week? 16:45:32 rkukura: We're going through the backlog, a few were given an extension. 16:45:56 mestery: If they don’t yet have +2 or -2, is there still hope for kilo? 16:46:36 Well, if they don't have a +2, it's more likely they'll get a -2, but there is slight hope. 16:46:41 :) 16:47:03 OK, if you have a spec you think needs to get approved for kilo, make your case with the drivers team! 16:47:06 :-) 16:47:16 And be responsive to an review comments! 16:47:20 OK, lets move on 16:47:28 about 13 minutes left 16:47:33 #topic Bugs 16:47:40 shivharis: Do you want to cover this? 16:47:52 kilo-1 is around the corner 16:48:17 bugs destined for kilo-1 but with little progress moved to k-2 16:48:33 anyone has k-1 bugs that need help/review/et 16:49:24 we have 4 high prior bugs that need attention, even though they got moved out to k-2 i hope they make it to k-2 16:49:38 https://bugs.launchpad.net/neutron/+bug/1179223 16:49:39 Launchpad bug 1179223 in neutron "Retired GRE and VXLAN tunnels persists in neutron db" [High,In progress] 16:49:42 romilg? 16:50:14 not sure if romilg is around, moving on.. 16:50:19 https://bugs.launchpad.net/neutron/+bug/1367391 16:50:20 Launchpad bug 1367391 in neutron "ML2 DVR port binding implementation unnecessarily duplicates schema and logic" [High,Confirmed] 16:50:26 rkukura? 16:50:30 I expect to complete that one for kilo-2 16:50:40 ok 16:51:06 The HPB patches I rebased also touch the DVR schema 16:51:18 the next one is confusing, it started out as critical but the fix was not complete 16:52:17 rkukura: ileave it to to you to coordiante with DVR folks 16:52:21 https://bugs.launchpad.net/neutron/+bug/1378732 16:52:23 Launchpad bug 1378732 in neutron "migrate_to_ml2 script doesn't work for Juno release" [High,Incomplete] 16:52:56 markmacclain: ? (not sure if he monitors this meeting) 16:53:50 next: https://bugs.launchpad.net/neutron/+bug/1381536 (eugene?) 16:53:52 Launchpad bug 1381536 in neutron "ResourceClosedError occurs when neutron API run in parallel" [High,Confirmed] 16:54:32 appears folks are not around to respond, i will ping individually 16:54:51 do we want to continue with the bug related to bulk operations or should I abondon it? #link https://review.openstack.org/#/c/113999/ 16:54:52 any questions regarding bugs? 16:54:53 shivharis: thanks! 16:55:30 banix: Were we going to see what happens with the core API refactoring, and how it might effect this? 16:55:49 banix: I definitely would not abandon it 16:56:02 rkukura: yes 16:56:54 banix: In fact, why not see if we can get it merged first? 16:57:12 anything else on bugs? 16:57:15 3 minutes left 16:57:17 rkukura: ok 16:57:20 #topic Open Discussion 16:58:23 if nothing for open discussion, we can end early :) 16:58:45 thanks everyone! 16:58:46 meeting next week? 16:59:29 shivharis: good question - do we want to meet on the 24th? 16:59:29 shivharis: good question - do we meet next week? 16:59:57 My vote - we enjoy holidays :-) 17:00:03 +1 17:00:09 i second 17:00:27 OK, we’ll skip next week, but what about new year’s eve? 17:00:43 lets try to do that one 17:00:47 we can meet, but not at IRC 17:00:48 #endmeeting