15:00:22 #startmeeting manila 15:00:23 Meeting started Thu Jan 28 15:00:22 2016 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:26 hello all 15:00:28 The meeting name has been set to 'manila' 15:00:29 Hi 15:00:31 o/ 15:00:33 Hi 15:00:34 hello 15:00:41 hello 15:00:46 hello 15:00:50 hi 15:01:17 hi 15:01:23 xyang markstur_: courtesy ping 15:01:47 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:02:29 so a few of us are sitting in the cinder midcycle today 15:02:39 so there might be minor distractions 15:02:50 but let's get going 15:03:00 #topic Hierarchical port binding support 15:03:09 mkoderer: you're up 15:03:11 ok so that's mine 15:03:22 we are thinking about Hierarchical Port Binding for manila 15:03:35 for those of you that never heard about it: https://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-hierarchical-port-binding.html 15:03:58 I've taken a look at this (briefly) and it seems like a great idea 15:04:10 so it's a technique to fix the VLAN 4096 limitation with an hierachical architecture 15:04:26 this solves a problem that we (the manila team) has been struggling with for 3 years 15:04:29 we are collection idease here currently: https://etherpad.openstack.org/p/manila-hierarchical-port-binding 15:05:02 I will have a meeting with some network experts tomorrow to get much more details 15:05:14 * mkoderer is not a network expert 15:05:15 I wasn't aware that neutron had already done the hard work here -- I always assume we would have to solve this problem in manila 15:05:40 the idea is that we find a implementation that is manila driver independent 15:05:53 so I know a lot about networking, but very little about neutron in particular 15:06:25 mkoderer: is it possible that a solution could be created without even modifying manila? 15:06:26 <-- lurks in quickly 15:06:35 or do we need to make some changes? 15:07:28 bswartz: mh I mean it's always possible to assign a port manually 15:08:04 but I think get it triggered and managed with manila would be the most convenient way 15:08:22 well NetApp has a driver that works with vlan but not vxlan 15:08:39 so we tell customers they have to use vlan only with neutron if they use the share-server version of our driver 15:08:55 do we have other drivers that only support vlans? 15:09:00 if we can demonstrate a config that makes that unnecessary that would be a huge win 15:09:23 and if there are gaps, then those are the things we should address with the above BP 15:09:32 mkoderer: I think one of the EMC drivers may 15:09:51 mkoderer: EMC and Huawei probably... 15:09:58 ok good.. I need to have a look to this drivers too 15:10:11 mkoderer: you can grep the drivers to find out for sure, or ask on the ML 15:10:19 bswartz: sure 15:10:34 so plan is that we open up a lp bp in the next days 15:10:49 so I think it's too late to do this in Mitaka, unless it turns out to be pretty small 15:11:05 however it could land early in Newton 15:11:17 IMO that's what we should aim for 15:11:32 bswartz: yeah.. we need to get it ASAP :) so N-1 would be good 15:11:39 okay 15:11:47 one open issue is QA 15:12:05 since testing it needs a network fabric that supports HPB 15:12:10 mkoderer: are you volunteering to do the needed proof of concept and dev work yourself or do you need help? 15:12:26 oh that's a good point 15:12:49 I can ask around at NetApp since they stand to gain a lot from this BP 15:13:11 if I shake the right trees some money or hardware might fall out 15:13:15 bswartz: yeah so I will be the assignee 15:13:36 bswartz: that's what I wanted to hear :) 15:13:47 that could take several weeks though 15:14:01 since we won't build a 3rd vendor test facility 15:14:10 very high trees? )) 15:14:25 okay anything else before we move on? 15:14:25 bswartz: yeah let's discuss this when we have someting more in detail :) 15:14:31 nope 15:14:47 #topic Core reviewer team and other manila-related projects 15:15:01 so just a reminder that we currently operate 4 repos: 15:15:14 manila, manila-ui, python-manilaclient, and manila-image-elements 15:15:27 all of them except manila-ui have the same core reviewer team 15:15:45 manila-ui has our core reviewer team plus horizon's 15:16:23 we need core reviewers to make sure they're looking at all of those repos, otherwise patches will get stuck 15:16:50 if that turns out to be too much work, we could look at expanding the core reviewer teams for some of the smaller projects 15:17:04 manila-image-elements in particular is a different type of project 15:17:35 is there any interest in expanding the core reviewer teams for the subprojects independently of the main manila project 15:17:39 ? 15:18:19 ..... 15:18:46 bswartz: which one does have the most pending reviews? 15:18:49 * bswartz taps the microphone 15:19:03 Those reviews are usually pretty small. More an issue of testing and QA. 15:19:12 mkoderer: the most work is still in the main manila project 15:19:15 We can use more +1s always. 15:19:42 I will add those project to my gerrit query :) 15:19:49 however manila-image-elements has been needing the most attention 15:19:54 even though I have no idea about manila-image-elements 15:20:00 If we have someone focus on something like image then it would be fine to expand 15:20:08 okay maybe the problem is just not enough awareness 15:20:33 we should also check that stackalytics has the right associations so people are credited for their reviews there 15:20:39 (I wasn't watching image elements at all until bswartz brought it up earlier) 15:21:04 I tend to search in manila and forget about other subprojects. it is an issue of awareness as well 15:21:10 okay let's see if things get better now that we've reminded everyone 15:21:37 * gouthamr_ expands watched projects 15:21:40 Otherwise we could just expand core for all of them together 15:21:49 if it's still a problem we can revisit the concept of expaning the core reivewer teams later 15:21:56 moving on.... 15:22:24 #topic Replication status 15:22:38 so the replication code has been in review for a long time now 15:23:02 I hope nobody has any objections they haven't raised yet because I'm hoping to see it merge very soon 15:23:29 my own remaining objection is around the first party driver support and it looks like that will be solved shortly as we finally have a promising solution using ZFS 15:23:55 bswartz: will have some results when I do some POC generic driver support 15:23:59 we are going to start running up against deadlines starting in 2 weeks 15:25:18 once we have a POC posted, I will want to start workflowing the core code immediately 15:25:55 so this is just a reminder: do your reviews of the replication code now if you haven't already 15:26:32 I expect to see merge conflicts, and there are other important new features too 15:27:00 I really hope we manage M-3 better than L-3 went, so my approach will be to start sooner 15:27:04 bswartz: is there netapp driver support for replication? 15:27:59 gouthamr: is it somehow not in gerrit??? 15:28:03 vponomaryov: it's being developed downstream, will be up for review soon 15:28:09 +1 15:28:12 WTF? 15:28:20 how it that not upstream? 15:28:36 gouthamr_: good to know 15:28:49 push it up today please 15:29:32 bswartz: will do. 15:29:35 thx 15:29:53 the netapp support has been working since tokyo 15:30:19 although there have been changes since then obviously 15:30:37 okay that's all I had to say on that topic 15:30:42 #topic open discussion 15:30:47 anything else for today? 15:30:49 #link https://review.openstack.org/#/c/245126/ 15:30:55 that should be ready for reviews 15:31:04 it is not passing jenkins because jenkins broke today 15:31:10 but I added a "depends-on" 15:31:18 so it should work now... it is in zuul's queue 15:31:52 ganso: thanks 15:32:11 that's also urgent to get merged 15:32:23 * bswartz puts a gold star on 245126 15:32:46 I advise all driver maintainers to rebase on top of that patch and implement update_access() in their drivers 15:33:11 mkoderer: do you have a specific city for the summer midcycle proposal yet? 15:33:13 do not wait until it merges 15:33:22 ganso: +1 15:35:26 mkoderer: ? 15:35:46 I think we need to start asking about travel soon if that's going to happen 15:36:04 I really like the idea of being more friendly to our european team members 15:36:07 I also, it is important to note that the fallback approach in that patch MUST be removed later in Mitaka... we should not have drivers holding it back 15:36:58 okay I think we lost mkoderer 15:37:05 I think we're done for today 15:37:07 thanks all 15:37:18 thanks 15:37:19 #endmeeting