15:00:19 #startmeeting manila 15:00:19 Meeting started Thu Sep 3 15:00:19 2015 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:24 The meeting name has been set to 'manila' 15:00:30 o/ 15:00:30 hi 15:00:30 Hi 15:00:38 hi 15:00:39 hi 15:00:40 o/ 15:00:40 #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:00:43 o/ 15:00:53 \o 15:00:54 hello 15:00:55 hi 15:00:55 hi 15:01:07 also csaba has a topic he couldn't add due to an OpenID failure 15:01:20 hi 15:01:36 #topic liberty-3 / feature freeze 15:01:36 hi 15:01:45 hi 15:01:59 hi 15:02:05 so liberty-3 was tagged about an hour ago 15:02:14 #link http://git.openstack.org/cgit/openstack/manila/tag/?id=1.0.0.0b3 15:02:22 that's the good news 15:02:39 the bad news is that 7 blueprints and countless bugs were not merged due to a serious gate problem 15:03:13 do we know the cause of the gate issue? 15:03:21 we're going to grant technical FFE exceptions for stuff that was ready to merge when the gate broke 15:03:57 akerr: yes, https://bugs.launchpad.net/nova/+bug/1491325 15:03:58 Launchpad bug 1491325 in OpenStack Compute (nova) "nova api v2.1 does not allow to use autodetection of volume device path" [Critical,In progress] - Assigned to Davanum Srinivas (DIMS) (dims-v) 15:04:13 although a technical FFE is no gurauntee that stuff will get in to liberty 15:05:12 nova created a bug on Tuesday night which caused problems for us on Wednesday morning 15:05:53 bswartz: actually bug was for a long time, Nova switched us to place where it was located 15:05:54 just us or everyone who touches nova? 15:06:14 they create a server fix, then blocked the fix, then created a client fix, but did not tag the client fix so it wouldn't help us, and now they have unblocked the original server fix and it's on it s way through the gate again 15:06:31 dustins: Nova has bug in their API compatibility v2.1 -> v2.0 15:06:46 vponomaryov: Ah, I gotcha, thanks! 15:07:25 dustins: so this bug is not only for liberty, but also existing stable branches 15:07:36 the upshot is that if you add Depends-On: Ibfd83b6abdfeec328019246a372363cada53869e to your patch it should pass gate 15:08:07 bswartz: I thought what I'm to to is to rebase my patches over said one 15:08:12 or you can rebase on top of https://review.openstack.org/#/c/219788/ after valeriy updates that one to depend on Ibfd83b6abdfeec328019246a372363cada53869e 15:08:48 csaba: dep on https://review.openstack.org/#/c/219788/ can make gates more stable 15:09:11 csaba: because of workaround of another bug, now in Neutron 15:09:24 one way or another we will get past the gate problem 15:09:49 however we need to be aware that we are now eating into bugfixing time 15:10:18 vponomaryov: so you mean I should resubmit with "Depends-On: I26dd32b1de8cceeaa6dc674092efec683df71889" indeed 15:10:35 (id of https://review.openstack.org/#/c/219788/) 15:10:56 the FFE for technical reasons will only extend for around a day after the gate becomes unblocked (hopefully by tonight) 15:11:00 csaba: you can, but not forced 15:11:22 if stuff can't get workflowed by then we will have to push stuff out to mitaka 15:11:35 vponomaryov, You didn't update the depends on there yet 15:11:59 so anyone that has stuff waiting to go in, make sure you're online and actively working on making your stuff pass check jobs and get your +2s 15:12:07 markstur: 3 sec ago 15:12:10 markstur: =) 15:12:27 vponomaryov: +1 15:12:35 vponomaryov, took 4 secs to get to california 15:12:43 lol 15:12:48 bswartz: do we discuss the possibility of non-technical FFEs here? 15:13:13 csaba: for those we follow the regular process 15:13:15 is anyone abel to recommend python 2 versus 3 for converting a bunch of bash scripts ? 15:13:24 after you get a -2 you request exception on the ML 15:13:29 too windy, dove flies too slow =) 15:13:43 sorry for jumping into the meeting - 15:13:56 bswartz: why does something get a -2 that won't be merged to liberty? 15:14:01 I'll be watching the get closely today and I'll announce the all clear and set the deadline for stuff to merge 15:14:38 bswartz: Are you going to briefly review the 7 targeted BPs? 15:14:50 -2 is just to signal that something isn't ready for merge 15:15:01 OK 15:15:23 cknight: yes I want to assuming we have time 15:16:15 but the way I expect things to go in the next hour or 2 every patch should be resubmitted and start passing check jobs 15:16:49 when I see that I'll announce a deadline of Friday night or Saturday to get stuff merged again 15:16:59 and when the deadline arrives we'll -2 stuff as usual 15:17:50 bswartz: basically what's the difference between "Depends-On: Foo" and being rebased over Foo? 15:17:58 core reviewers: the moment you see +1 from jenkins start merging stuff that's ready to merge though 15:18:11 csaba: depends-on work across projects 15:18:30 csaba: honestly I'm surprised it works within a project 15:18:44 ah OK got it so the suggested depends-on because the referred fix is in nova 15:18:51 bulb's up! 15:18:59 bswartz: why surprised? 15:19:05 https://review.openstack.org/#/c/219788/ should be the first thing that's merged though 15:19:10 rbase also gives you a chance to deal with merge conflicts. I'd assume depends on would fail that 15:19:37 markstur: yes, it will, but while it is not, it is ok 15:19:44 vponomaryov: just because it's an inferior way to do things, for the reason markstur said 15:20:43 okay so let's quickly go through the remaining BPs and bugs and see if any need discussing 15:21:03 #link https://launchpad.net/manila/+milestone/liberty-rc1 15:21:17 #topic share migration 15:21:55 So my concern with share migration is the lack of functional tests. I haven't yet succeeded in getting migration to work. 15:22:00 this has a -1 about functional tests 15:22:12 ganso_: can you add functional tests for it? 15:22:24 bswartz: I can start working on it right now 15:22:29 This is a major feature, albeit experimental, so it should have some level of Tempest coverage. 15:22:47 yes my stance is that all features need funcitonal tests coverage 15:23:21 ganso_: I also think the concern that others can't get it to work is a problem 15:23:26 There's always a trade-off of something "experimental" going late in release vs early in the next 15:23:31 who else has downloaded and tested migrations? 15:23:45 crickets 15:24:00 bswartz: I need to see logs and check what errors are poping up 15:24:06 markstur: the whole point of "experimental" is to make those kinds of distinctions matter less though 15:24:29 we're on a 6 month release cycle, which is fairly fast 15:24:47 Agreed. I like it as experimental. I would suggest waiting otherwise. 15:24:48 if something misses one release and slips to the next it should not be a big deal 15:25:04 however experimental lets us merge stuff when its ready and get feedback earlier 15:25:21 bswartz: I think that since we are marking it experimental, most bugs, edge cases, incompatiblity with some driver vendors, will be detected in liberty 15:25:34 so there are 2 concerns that need addressing with migrations 15:25:38 bswartz: but experimental should still work in the majority of common cases 15:26:01 bswartz: if we slip to mitaka, it might still not have a very good coverage because not many people would have tested it 15:26:02 akerr: experimental APIs should work in at least 1 common case 15:26:05 akerr: +1 Ready == working in some capacity. It could be something I'm doing, but I need to see it working in host-copy mode with my driver. 15:26:58 1 common case seems like a really low bar 15:27:24 we cannot guarantee it will work with all drivers at this moment, that is why it is experimental 15:27:38 I would still like to see migration in liberty, but as we know it needs enhancements in mitaka anyways to work in all cases it would not be terrible to delay the feature 15:27:40 akerr: +1, experimental shouldn't mean half done (lets avoid a philosophical debate) 15:27:46 but if it is proved to work with generic driver (and I understand functional test would help prove that) then it is something 15:28:07 ganso_: +1 Working tests will go a long way. 15:28:09 ameade: yes that's important 15:28:11 ganso_: I am cool with it only working with generic 15:28:17 ganso_: +1 15:28:37 however ganso_ has had code in gerrit for MONTHS and nobody started seriously testing it until last few weeks 15:28:58 agree, i just don't think experimental should be used to merge what are essentially WIP patches. If it works in generic that's fine 15:29:05 bswartz: +1 15:29:41 liberty has been complicated with the dependencies caused by share instances 15:29:45 akerr: functional tests say us that it works 15:29:55 I also had a patch to work without share instances, we discussed that in a meeting, the one which had a driver_id field 15:29:57 akerr: there is no such for the moment 15:30:00 let's give ganso_ a chance to add functional tests and show that it works 15:30:28 we have to move on due to time 15:30:39 +1 15:30:44 #topic consistency groups 15:30:58 +1 for working working migration (and moving on) 15:31:02 this one has 4 patchsets 15:31:38 5 if you include generic driver and tempest tests 15:31:39 there are 5 changesets if you count generic driver 15:31:46 support for CGs was added to the generic driver recently at my request 15:31:46 markstur: do not say twice twice =) 15:31:52 #link https://blueprints.launchpad.net/manila/+spec/manila-consistency-groups 15:31:55 akerr: ^ 15:32:40 bswartz: https://review.openstack.org/#/c/215346/ 15:32:41 most of these patches have been reviewed by vponomaryov, u_glide, and xyang1 15:33:00 first patch in the chain 15:33:02 #link https://review.openstack.org/#/c/215343/ 15:33:07 looks like the base of the dependency chain now has a depends-on for valeriy's gatefix so we should see these pass check jobs in an hour or so 15:33:09 ameade: I've also reviewed them extensively internally for weeks. The quality is high, IMO. 15:33:40 there are patches for both netapp cdot and generic driver support 15:33:47 it's been heavily tested with both 15:33:49 u_glide: We need you to look at the rebase on share instances. 15:33:52 xyang1: you were the one who raised concerns about the API design with this one, are you satisfied? 15:34:01 bswartz: Nova's one of jobs failed 15:34:09 cknight: I will take a look 15:34:25 bswartz: I have not got chance to take another look 15:34:37 u_glide: ty, i added all the unittest coverage i had missed and i believe i addressed all the other comments 15:34:59 xyang1: if you have issues express them soon 15:35:10 bswartz: Ok 15:35:12 otherwise I feel okay about merging CGs 15:35:28 they will need to be rebased on top of version 2 when that merges 15:35:53 it was just before the deadline, but the quality was good, and furthermore the way the feature is implemented puts little risk on existing codepaths 15:36:35 most importantly, it's marked experimental so we can fix anything that needs fixing or we can even choose to revert it in mitaka if it turns out to be terrible 15:36:39 v2 patch should be leaving our internal gate in about 8 minutes 15:36:43 bswartz: It will be better for such a big change to be submitted earlier though 15:37:00 xyang1: absolutely agree 15:37:22 I set the deadline so that we'd all have 2 weeks to review stuff 15:37:38 for manila-client, we have CG and migration in "L3" 15:37:48 if 2 weeks isn't enough for big things we need to talk about moving the FPF date for Mitaka to 3 weeks maybe 15:38:03 I assume those go with the features 15:38:08 But such a big change should have more than 2 weeks review time 15:38:16 markstur: the client LP is a bit of a mess 15:38:19 markstur: +1 15:38:29 bswartz: i thought we discussed at Vancouver that CGs for file systems didn't really apply as they do for block, or did I miss something 15:39:11 markstur: we'll clean that up later 15:39:36 xyang1: what do you propose? an earlier deadline for "big" features and a later deadline for "small" features? 15:39:51 bswartz: I think that is better 15:39:57 it's not a bad idea, except that it will be hard to draw the line between big and small 15:39:57 I guess my question is, what is the use case for CGs for file systems? Was one found? 15:40:00 lpabon_: There are definitely use cases for CGs with file systems, most notably databases with data and logs on different paths. 15:40:41 everyone will claim that their feature is really small 15:40:53 cknight: ah i see, so that logs could be on a different volume type, since they are write only 15:41:00 well, no one will claim that for CGs :-) 15:41:04 lpabon_: the database that uses multiple shares use case was a compelling one for me 15:41:33 bswartz: +1 for moving FPF earlier. 15:41:58 At mid-cycle it seemed we'd wait on CG until we had better defined customer need. It seeme "experimental" has helped move things up (plus working code!) 15:42:00 yeah, i could see that, but most of dbs that do that use raw access to block storage afaik... but I could see a use case for file based logs 15:42:02 the topic of the Mitaka FPF will be discussed and decided later 15:42:24 in the interest of time we have to move on though 15:42:38 again, please use gerrit to provide feedback 15:42:59 #topic Mount Automation Framework 15:43:07 #link https://blueprints.launchpad.net/manila/+spec/mount-automation-framework 15:43:07 bswartz: We can measure by number of lines, not include tests? 15:43:12 #link https://review.openstack.org/#/c/201669/ 15:43:19 I've read through this one, it seems fine. 15:43:29 vponomaryov: ^ needs rebase 15:43:43 bswartz: why? 15:43:46 xyang1: let's discuss it in tokyo 15:43:50 Ok 15:43:53 bswartz: it is ok, its dependency is merged 15:43:54 vponomaryov: gate fix 15:43:59 But I'd again ask about Tempest coverage. vponomaryov, is it needed? 15:44:17 cknight: it is desired 15:44:28 cknight: but we do not have strict requirement 15:44:29 cknight: this feature is an internal one -- no API impact 15:44:38 bswartz: Good point. 15:44:55 bswartz: We still want a contrib example of how a client could use this for automounts, right? 15:44:56 the plan was to provide samples for how it can be used, but ultimately it's up to admins to implement the hooks 15:45:11 cknight: yes I'm expecting contrib/docs samples for how to use this feature 15:45:12 cknight: we have POC in gerrit 15:45:17 but the feature itself looks mergeable to me 15:45:23 bswartz: +1 15:45:36 note: it is in "base" condition 15:45:43 and definitely will require updates 15:45:58 vponomaryov: Can you clarify? What else is needed? 15:46:29 vponomaryov: rebase on top of https://review.openstack.org/#/c/219788/ would make it easier to pass through gate 15:46:35 cknight: like ganso proposed , could be added info about share servers in notification 15:46:46 cknight: that is not there atm 15:46:59 cknight: is there a way for a driver to use the automount code to insert something into the VM.. like say.. a glusterfs ssl certificate :-) 15:47:15 lpabon_: it's not a feature for drivers, it's a tool for the admin 15:47:27 :( 15:47:34 the admin could choose to use it in the way you suggest 15:47:40 :) 15:47:43 cool 15:47:49 but we'd need to provide docs/samples for that use case and it would be up to the admin to do it 15:48:06 true 15:48:36 the tricky thing about mount automation is that because it means so many different things to different people, all solutions will have to have some administrator involvement 15:48:39 there is local fix for Nova bug: https://review.openstack.org/#/c/220204/ in Manila 15:49:03 there will never be a one-size-fits-all mount automation solution I'm afraid 15:49:17 please register issues with that patch in gerrit if you have any 15:49:20 moving on... 15:49:50 #topic tempest plugin 15:49:57 #link https://blueprints.launchpad.net/manila/+spec/tempest-plugin-interface 15:50:12 #link https://review.openstack.org/#/c/201955/ 15:50:28 mkoderer: you here? 15:50:43 I've been trying to get this one to pass gate 15:51:29 the silence is really loud on this one 15:51:43 I'll assume no discussion is needed and we'll try to keep it moving 15:51:47 bswartz: I don't understand the benefit of this one. 15:51:51 please review it if you have issues 15:52:11 #topic Add Windows SMB share support 15:52:15 cknight: benefit of having tempest plugin? 15:52:19 #link https://blueprints.launchpad.net/manila/+spec/windows-smb-support 15:52:21 vponomaryov: yes 15:52:33 #link https://review.openstack.org/#/c/200154/ 15:52:41 cknight: clear interface and no hacking on tempest 15:52:42 bswartz: The Windows driver has been reviewed and is ready, we've just been waiting on CI voting. 15:52:49 this hasn't been through the check pipeline since the gate breakage 15:53:05 vponomaryov: OK, I'll defer to your Tempest expertise, then. 15:53:07 I think it's ready but lpetrut might need to rebase it 15:53:14 cknight: +1, waiting for CI reporting that it is able to create shares in general 15:53:47 any discussion on new Windows SMB driver 15:54:10 bswartz: where is image for it? 15:54:25 lpetrut? 15:54:33 this driver has CI, although it's a little funky at the moment 15:54:46 the reporting format is garbled, but it's clearly running 15:55:27 vponomaryov: raise your issues in gerrit please 15:55:39 #topic Consistency groups in NetApp cDOT drivers 15:55:43 bswartz: This one goes hand-in-hand with CGs, and it's been tested thoroughly with akerr's CG Tempest tests. It was used as a model for the generic driver CG patch. 15:56:03 bswartz: Shouldn't be controversial ;-) 15:56:21 yes hopefully this should be a no-brainer assuming the CG core work is fine 15:56:35 also it can serve as a model for others implementing CGs 15:56:58 although if anyone has issues raise them in gerrit 15:57:06 #topic (last one) GlusterFS 15:57:13 this has a large number of patches 15:57:26 #link 15:57:28 bswartz: Yes, and limited reviews on some of them. 15:57:29 #link https://blueprints.launchpad.net/manila/+spec/modular-glusterfs-share-layouts 15:57:44 csaba: Is this an all-or-nothing thing? 15:57:50 csaba: does these ALL need to go in or can we start merging from the root? 15:57:56 lol same question 15:58:12 cknight: well the point of the whole series is the last two patches 15:58:23 okay 15:58:43 well splitting it up for the reviewer's benefit is appreciated 15:59:01 I guess we'll ask reviewers to review the whole chain though and workflow backwards 15:59:08 bswartz: The code seems OK, although there are some unit test gaps in exception paths I'd like to see covered. 15:59:23 cknight: coverage is now at ~100% 15:59:33 csaba: Thanks, I'll look again. 15:59:40 csaba: have you rebased on the gate fix? 15:59:49 gah we're out of time! 15:59:57 we need to discuss bugs 15:59:58 bswartz: rebased yesterday over the patch you inidcated 16:00:05 isthat the same as said today? 16:00:08 please come over to the #openstack-manila channel to discuss bugs 16:00:19 #endmeeting