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