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