15:02:13 <bswartz> #startmeeting manila 15:02:14 <openstack> Meeting started Thu Jul 2 15:02:13 2015 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:18 <openstack> The meeting name has been set to 'manila' 15:02:21 <ganso_> #link https://review.openstack.org/#/c/193664/ 15:02:32 <ganso_> I just got back from vacation 15:02:48 <ganso_> I do not know if anyone has taken a look at this patch I submitted 10 days ago 15:02:50 <bswartz> welcome back! 15:02:54 <ganso_> bswartz: thanks! 15:03:06 <bswartz> ganso_: half the manila core team is still on vacation until next week 15:03:18 <ganso_> bswartz: o_O 15:03:42 <ganso_> bswartz: what's the occasion? I did not know there was a planned vacation 15:03:47 <bswartz> this week there are holidays in the USA 15:03:56 <ganso_> bswartz: oh, 4th of July 15:04:11 <ganso_> bswartz: nice 15:04:25 <ganso_> so, my patch is mostly an example implementation 15:04:39 <bswartz> it looks like it has no reviews so far 15:04:40 <ganso_> so we can take a look of what effort is needed to implement something that can work for Share Migration 15:04:44 <bswartz> it's small though so I can take a quick look 15:05:00 <ganso_> Also, there is this patch for generic driver, based on that one I just posted 15:05:01 <ganso_> #link https://review.openstack.org/#/c/193667/ 15:05:17 <xyang1> ganso_: is this a POC, or something that you are planning to be merged 15:05:18 <ganso_> I did not have time to fix the unit tests for time before leaving for vacation though 15:05:23 <bswartz> I believe that u_glide started working on a proposal for share instances (2 IDs) last week 15:05:48 <bswartz> looks like POC 15:05:50 <ganso_> xyang1: this is initally a PoC, if we end up agreeing that it looks good, and the proposal solves our problems for Share Migration, we may improve and merge it 15:05:59 <xyang1> ok, thanks 15:06:12 <ganso_> I also just stumbled across another scenario where this patch may be useful 15:06:20 <ganso_> my mate over here is working on a driver 15:06:34 <bswartz> I believe that u_glide's share instance work will be how we will ultimately implement 2 IDs per share 15:06:52 <bswartz> ganso_: what is the other scenario 15:07:00 <ganso_> bswartz: has u_glide started working on it? 15:07:13 <markstur> hi. sorry late 15:07:21 <bswartz> ganso_: yes but he and vponomaryov are both on vacation this week too 15:07:32 <ganso_> while implementing Manage feature, today he has either to rename to rename share, or use private driver storage 15:07:47 <ganso_> rename the share on the backend 15:08:04 <bswartz> okay 15:08:14 <bswartz> both of those approaches work today 15:08:18 <ganso_> with this patch I created, he may store the original share name (from the backend) in the driver_id column 15:08:31 <bswartz> gah! 15:08:39 <bswartz> no I don't think that would work 15:08:59 <bswartz> because even if we have another ID collumn it shouldn't be modifiable by the driver 15:09:33 <ganso_> in fact it would return a model update for the manager, who would edit that field when Manage method is finished 15:09:37 <xyang1> bswartz: so we will be comparing u_glide's approach with ganso_'s and decide which one to use finally? 15:10:01 <ganso_> xyang1: possibly 15:10:26 <bswartz> xyang1: yes 15:10:27 <ganso_> share instance approach is probably the best, but will require more effort 15:10:52 <ganso_> my approach required small effort on core code, and small effort on driver code 15:11:00 <bswartz> however u_glide's approach will be a more general version of this 15:11:13 <bswartz> it's good that ganso_ has this proposal to start working from 15:12:17 <xyang1> to avoid confusion, I think both of you should reference each other's patches then. Or in the commit message, state that there's another approach being worked on 15:12:35 <bswartz> I really want to see migration happen so anything that can unblock ganso's work is something I'll support 15:12:47 <ganso_> xyang1: +1, I can update my commit message 15:12:58 <bswartz> I marked ganso's patch WIP 15:13:31 <xyang1> that is better. thanks 15:13:36 <ganso_> I can continue work on share migration with my patch 15:13:48 <ganso_> like, experiment more on the copy command 15:13:52 <ganso_> etc 15:13:54 <bswartz> I hope that u_glide's patch will arrive soon and ganso_ will be able to rebase on top of that 15:14:10 <bswartz> but it if takes another week or 2 then ganso can continue working based on this 15:14:43 <bswartz> I'll review it but most likely -1 with a recommendation that we hold off 15:14:50 <bswartz> sound good? 15:14:52 <ganso_> bswartz: that would be great 15:15:15 <ganso_> bswartz: but I am not really about this right now, if eventually we are going to accept either one or the other 15:15:39 <bswartz> markstur: the meeting today is short as most people are on vacation 15:15:51 <bswartz> markstur: (and there is no agenda) 15:15:55 <ganso_> bswartz: I am worried about polishing Share Migration, I wish more people get involved with the implementation before merging the ID patch 15:15:57 <markstur> bswartz, Yes. It's been quiet this week 15:16:19 <ganso_> such as this #link https://review.openstack.org/179790 15:16:22 <bswartz> ganso_: let me know what I can do to help 15:16:44 <bswartz> okay I'll review this too 15:16:59 <ganso_> bswartz: I remember the last topic we discussed regarding Share Migration (not related to IDs), is about the methods the drivers would need to implement to provide the network path 15:17:11 <ganso_> if that approach is ok, then it is up for review 15:17:41 <ganso_> the copy command is a bit unstable, but I am focusing on that now 15:17:48 <bswartz> unstable how 15:17:58 <ganso_> rsync -vza sometimes fails to copy some files 15:18:04 <bswartz> did you decide that cp -a doesn't work? 15:18:06 <ganso_> I/O error or something like that 15:18:13 <bswartz> oh hmm 15:18:22 <ganso_> I am thinking about using a python library that copies all the files 15:18:24 <bswartz> just some files not all of them? 15:18:34 <ganso_> yea, just some files, randomly 15:18:42 <ganso_> I performed several tests, it fails randomly 15:18:50 <bswartz> that's really weird -- which backends did you try? 15:18:59 <ganso_> only generic for now 15:19:06 <ganso_> like, 10 files, sometimes it copies all of them, sometimes copies 8, etc 15:19:20 <bswartz> how are you generating the initial set of files? 15:19:34 <ganso_> the most dangerous thing is that, after migration, the original share is deleted, so files not copied are lost forever 15:19:49 <markstur> yikes 15:19:53 <ganso_> rsync -vza on share root is recursive 15:20:06 <bswartz> yeah I think it's important that the copy command returns failure if it detects any error so the migration can be stopped 15:20:33 <ganso_> so currently I do not generate a list of files. When using the python library I will be able to list all files, exploring the directory tree, and also know the copy progress 15:20:35 <bswartz> that would at least prevent the original from getting deleted 15:20:49 <bswartz> rsync doesn't return an error status? 15:20:50 <ganso_> yea but there are some scenarios that cannot be copied 15:20:54 <ganso_> such as the lost+found folder 15:21:04 <ganso_> I mean, not sure if cannot be copied 15:21:16 <ganso_> but seems like it, I haven't looked much into this particular case 15:21:53 <bswartz> okay well please make sure you check for errors and fail the migration if everything doesn't go perfectly 15:22:10 <bswartz> if manila sometimes deletes people's data during migration we won't be very popular 15:22:29 <bswartz> we'll have to triple check all that logic in the code review too 15:22:59 <ganso_> rsync does return error code if anything failes, although it continues to copy everything, but for instance, the lost+found folder is always failing. There is a way to pass a list of folders/files to ignore as parameters also... but the copy must be stable, currently it is not 15:23:31 <bswartz> I think I can understand lost+found 15:23:39 <ganso_> so, using this python library I expect to have a much finer-grained control 15:24:00 <ganso_> I don't remember the name now, I have to look it up, but openstack already uses it 15:24:03 <bswartz> that's created by the filesystem -- it shouldn't be user-modifiable 15:24:41 <ganso_> yes but we need to acknowledge the user that his files in his lost+found folder are going to be lost on migration 15:24:41 <bswartz> okay 15:25:10 <bswartz> or we need to move them to a differently-named folder during the migration 15:25:24 <bswartz> or ask the user to delete them before migrating 15:25:40 <ganso_> yes 15:25:59 <bswartz> I can see some strange user experiences coming out of this 15:26:22 <bswartz> various limitations around data copying 15:26:45 <bswartz> we'll need to make sure they get documented 15:26:50 <ganso_> that's why I think we need to have Share Migration unblocked for review, test, and general use asap, it takes a lot of time to get it ready for primetime 15:27:09 <bswartz> yeah 15:27:24 <bswartz> okay thanks for this update 15:27:34 <bswartz> anything else from you ganso_? 15:27:42 <markstur> ganso_, So you'd really like driver vendors to start using it now? 15:28:18 <ganso_> bswartz: not really, I haven't had progress in the minimum requirements documentation task, it is still in etherpad 15:28:22 <bswartz> markstur: I think he means people should test it out and provide code reviews 15:28:35 <ganso_> markstur: if driver vendor maintainers can start testing it, it would be great 15:28:48 <ganso_> markstur: if they expect to have it supported on Liberty 15:28:50 <markstur> OK. I was thinking if he's ready for early adopters for POC. He should be recruiting a little. 15:29:19 <bswartz> the best code review is: I downloaded and ran your code and it blows up in this corner case you missed 15:29:22 <ganso_> markstur: from what has been decided so far, they would have to implement a few functions here and there, the network path. 15:29:45 <ganso_> bswartz: +1 15:29:47 <ganso_> yea 15:30:18 <ganso_> since this ID patch came after it, I should edit the commit message and add more description, like, for testing the PoC, it is advisable to download the ID patch 15:30:27 <bswartz> hopefully everyone knows about git review -d for downloading patches 15:31:10 <bswartz> did anyone have another topic for today? 15:31:12 <ganso_> bswartz: pardon my ignorance, I am not familiar with it 15:31:14 <markstur> 2 things... 15:31:22 <ganso_> bswartz: what is -d for? 15:31:27 <bswartz> ganso_: try it out 15:31:33 <ganso_> bswartz: ok 15:31:34 <bswartz> git review -d <change number> 15:31:45 <bswartz> it pulls a change out of gerrit into your local workspace 15:31:59 <ganso_> oh, I always do git fetch and rebase 15:32:06 <ganso_> it will make my life easier 15:32:06 <bswartz> markstur: go ahead 15:32:09 <markstur> 1. notice the manila-coverage (non-voting) job on patch sets 15:32:17 <markstur> very handly coverage report 15:32:32 <markstur> you should run your own anyway, but I like this for reviews 15:32:53 <markstur> Boris suggested a way to make it voting if coverage gets worse! But I don't know if we want that yet 15:33:12 <markstur> I'd leave that up to reviewers for now 15:33:22 <markstur> 2. Some of our schedule stats tests don't consistently pass. I should have a fix for that soon. 15:33:35 <bswartz> cool 15:33:38 <markstur> was seeing a lot of false negatives 15:34:02 <markstur> bswartz, cool that tests are random or cool coverage report? 15:34:03 <markstur> :) 15:34:19 <bswartz> markstur: this seems to be measuring coverage of the test files too though... 15:34:41 <bswartz> what is the point of code coverage in the test files? 15:34:42 <markstur> bswartz, Yeah. That's odd, but I just look at the other pieces 15:35:03 <bswartz> the aggregate number at the top (89%) might be too high because of that though 15:35:04 <markstur> Actually, I don't think it is intended, but it can show you if you managed to create tests that are not being ran 15:35:22 <markstur> Yep. I wouldn't want tests to be included in aggregate. 15:35:50 <bswartz> its interesing that some unit test files have very low coverage though 15:35:59 <bswartz> I guess those would be worth looking into 15:36:35 <bswartz> and I'm not opposed to a gate test that fails if it detects a decrease in coverage -- although it strikes me that that could be dangerous 15:36:47 <bswartz> we'd want to keep it nonvoting for a while 15:36:54 <markstur> bswartz, Sure. So I think one step at a time. 15:36:59 <bswartz> the mechanism for detecting a decrease could be similar to what pylint does 15:37:43 <bswartz> so the other thing, about the scheduler stats tests 15:37:48 <bswartz> can you provide a link? 15:38:06 <markstur> I'll look not sure how quickly. 15:38:21 <markstur> But there is a stats dict compare that fails on timestamp of stat changes. 15:38:28 <bswartz> we've had unstable tests in the past but I'm not aware of the problem you mentioned 15:38:37 <markstur> And in my tests I also see set() used with non-hashables 15:39:00 <bswartz> did you file a LP bug? 15:39:12 <markstur> did not yet 15:39:29 <bswartz> maybe file a bug and assign it to yourself (assuming you plan to fix it) and capture the problem there 15:40:01 <markstur> http://logs.openstack.org/56/197256/3/check/gate-manila-tempest-dsvm-neutron/55771f1/console.html 15:40:28 <markstur> Yes. I'll do the LP bug. Should've done that right away. Then I'd find the link faster. 15:40:56 <bswartz> oh wait is this using the assert_dict_match function? 15:40:58 <markstur> I don't know why the set() not hashable was only found locally. So I'll make that separate. 15:41:21 <bswartz> that function has some weird logic in it to do "fuzzy" matches which I really don't like 15:41:39 <markstur> assertDictEqual 15:42:07 <bswartz> that's the one 15:42:11 <markstur> but the stats timestamp changes. so our tests tend to fail as things get slower 15:42:17 <bswartz> okay 15:42:23 <bswartz> yeah that's bugworthy 15:42:50 <bswartz> if you don't plan to fix it then we need to find an assignee with bandwidth 15:43:13 <markstur> I'll fix it right after the meeting 15:43:26 <bswartz> I think everyone will be back in their respective offices on Monday, except toabctl 15:43:33 <bswartz> thanks markstur 15:43:52 <bswartz> okay if nobody has other topics I think we're done 15:44:04 <bswartz> thanks for pointing out the coverage reports, those are cool 15:44:22 <bswartz> next week we'll have a regular meeting with an agenda 15:44:40 <bswartz> #endmeeting