15:00:15 <bswartz> #startmeeting manila 15:00:16 <openstack> Meeting started Thu Apr 23 15:00:15 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:19 <openstack> The meeting name has been set to 'manila' 15:00:22 <cknight> Hi 15:00:24 <toabctl> hi 15:00:24 <rraja> hi 15:00:26 <garysmith_> hi 15:00:26 <xyang2> hi 15:00:27 <vponomaryov> Hello 15:00:30 <ganso_> hello 15:00:42 <u_glide> hello 15:00:46 <csaba1> hi 15:00:57 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings 15:01:45 <bswartz> toabctl: since you asked, we now have stable/kilo of python-manilaclient 15:01:53 <bswartz> http://git.openstack.org/cgit/openstack/python-manilaclient/ 15:01:59 <toabctl> bswartz: cool. thx 15:02:06 <bswartz> stable branches of clients is a new thing 15:02:08 <Zhongjun> Hi 15:02:10 <markstur> hi 15:02:11 <bswartz> we will see how it goes 15:02:13 <rushil> hi 15:02:47 <bswartz> also, there are 2 core team nominations on the ML 15:02:48 <toabctl> bswartz: but I learned in #openstack-oslo that I should track the tagged versions 15:03:25 <bswartz> toabctl: okay -- at least we have a way to backport stuff to the kilo branch if we should need to 15:03:33 <toabctl> yes. 15:03:41 <tbarron> hi 15:03:44 <bswartz> #topic doc reviews 15:04:30 <bswartz> so there was a question a while back about what the procedure should be if you're reviewing a doc and you have a lot of comments 15:04:43 <bswartz> using gerrit to provide that kind of feedback is not ideal 15:05:04 <bswartz> it was proposed that reviewer should simply push their own edit patch back to gerrit with the changes made 15:05:12 <bswartz> reviewers* 15:05:20 <cknight> #link https://etherpad.openstack.org/p/docs-fixed-it-for-you 15:06:01 <bswartz> however if you do that while the original author is working on another revision, pushing a patch can do more harm than good 15:06:32 <xyang2> agreed, coordination with the original author is important 15:06:33 <bswartz> so my suggestion would be to talk to the original author first, and with permission, go ahead and push an edit patch 15:06:59 <bswartz> does that seem like a good process to follow for doc reviews? 15:07:07 <xyang2> doc team does that because non-doc author doesn't understand the syntax 15:07:22 <u_glide> + 15:07:23 <bswartz> for comments that might require debate we can still use gerrit reviews 15:07:31 <markstur> bswartz replied with a list of things to do. Seemed like if you follow the process it would cover the communication part 15:07:39 <bswartz> but for simple non-controversial edits this should hopefully save time 15:07:39 <xyang2> but if it has to do with the content, that is different 15:08:13 <markstur> "simple" can be done in gerrit to avoid conflict, though 15:08:20 <xyang2> +1 15:08:23 <bswartz> does anyone dislike the idea of pushing edits to other people's doc changes? 15:08:34 <cknight> xyang2: +1 The proposed mechanism is best for large numbers of simple grammatical or stylistic edits. 15:08:34 <bswartz> markstur: yeah if it's 2 or 3 small things then gerrit also works 15:08:34 <xyang2> I don't like it 15:08:42 <bswartz> when it's 200 small things gerrit doesn't work so well 15:08:45 <markstur> I dislike only if the author is suprised/annoyed by the "help" 15:08:51 <markstur> bswartz, _1 15:08:57 <markstur> bswartz, +1 i meant 15:09:11 <xyang2> I think the reviewer should get the author's permission 15:09:20 <bswartz> xyang2: yes that was the proposal 15:09:20 <vponomaryov> +1 xyang2, ok with "agreed" help 15:09:31 <bswartz> get permission, then push an edit patch 15:09:40 <toabctl> +1 15:09:59 <bswartz> xyang2: are you okay with that? 15:10:06 <xyang2> bswartz: yes 15:10:10 <bswartz> okay 15:10:47 <xyang2> if reviewer pushes up something that the original author doesn't like, then the original author can push back the original change. that will become a battle 15:11:05 <vponomaryov> probability is 99% =) 15:11:07 <bswartz> #agreed for multiple small doc comments that are non controversial, reviewers should push an edit patch rather than doing a gerrit review after obtaining permission from the original author 15:11:27 <bswartz> #topic liberty design summit 15:11:44 <bswartz> #link https://etherpad.openstack.org/p/manila-liberty-proposed-sessions 15:12:06 <bswartz> I still haven't added anything here 15:12:24 <bswartz> but this is the last week to make proposals, so I definitely will 15:12:41 <bswartz> and I encourage all of you to do so as well 15:12:43 <vponomaryov> Zhongjun asked about implementation of QoS 15:12:58 <bswartz> we have 7 slots in Vancouver 15:13:01 <toabctl> people should ad their names to the etherpad in the top-right corner 15:13:10 <bswartz> some of which conflict with cinder (I'm trying to fix that) 15:13:26 <markstur> I think the sched is alread "fixed" somewhat 15:13:38 <bswartz> markstur: that may be 15:14:00 <markstur> sched https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit#gid=569963128 15:14:14 <bswartz> in any case, some conflicts with cinder slots are unavoidable, so for anyone involved in both projects, I'm sorry 15:14:31 <markstur> still some overlap, but cinder is changing rooms, they will just think you got lost 15:15:13 <bswartz> okay 15:15:24 <bswartz> looks like 2 of our sessions got de-conflicted 15:15:35 <bswartz> the other 2 were unavoidable 15:15:47 <bswartz> thanks markstur 15:16:19 <bswartz> okay 15:16:34 <bswartz> vponomaryov: tell him to add it to the etherpad 15:16:53 <bswartz> all ideas should go on the etherpad 15:17:05 <bswartz> we can always prune and combine ideas 15:17:19 <bswartz> but if it's not on the etherpad it won't be considered 15:17:52 <bswartz> that's really all I have on the design summit 15:17:58 <bswartz> we'll spend most of next meeting on that topic 15:18:15 <bswartz> #topic Mount automation 15:18:23 <xyang2> bswartz: how long is each working session? 15:18:36 <bswartz> xyang: https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit?pli=1#gid=569963128 15:18:41 <cknight> In Paris, we started discussing mount automation. 15:18:43 <bswartz> times are on the left 15:18:53 <cknight> There were several suggestions from the community. 15:18:56 <bswartz> 40 minutes + 10 minute breaks 15:19:07 <cknight> One of them was zeroconf. Does anyone recollect who suggested that? 15:19:26 <vponomaryov> cknight: marcusvrn? 15:19:30 <bswartz> yes never got around to working on mount automation during kilo, so it's high on the list for Liberty 15:19:39 <bswartz> we* never 15:20:07 <cknight> Thanks, vponomaryov, I'll reach out to him. We've been researching zeroconf, but it doesn't seem like a panacea. 15:20:29 <bswartz> zeroconf sounded really attractive when we discussed it in Paris 15:20:37 <cknight> In fact, all options have limitations, so it will probably require a multi-faceted solution. 15:20:50 <bswartz> but after looking at it more closely it has drawbacks like all the other proposals 15:20:58 <cknight> Does anyone here have a suggestion we should be researching? 15:21:09 <bswartz> we're still looking for a silver bullet for mount automation 15:21:42 <cknight> Next on my list to look into is automounter + LDAP, but that isn't a self-contained solution. 15:22:02 <bswartz> I'm sure mount automation will be one of the topics in vancouver, and cknight will be driving it 15:22:16 <cknight> Hearing nothing, does anyone here *care* about mount automation? 15:22:42 * bswartz wonders if people don't understand what we're talking about 15:23:00 <u_glide> :) 15:23:01 <toabctl> who added the nova API suggestion to the etherpad? 15:23:34 <markstur> cknight, we *care* 15:23:37 <bswartz> oh yes this is important 15:24:05 <bswartz> if you add something to the etherpad, include your name in parentheses (bswartz) 15:24:33 <bswartz> so we know who is proposing what, so we can get more information when something isn't clear 15:25:06 <newbism> etcd stuff with autofs? 15:25:11 <toabctl> what are the requirements we want to focus? is windows support important? baremetal or only virtual? 15:25:11 <bswartz> okay, so by next week we'll have the proposal for the topic posted, included some background on what the problem is and our general idea for solving it 15:25:20 <u_glide> bswartz: Could you please share investigation results? 15:25:48 <bswartz> u_glide: we'll share what we know, but I expect research will be ongoing until the design summit 15:26:08 <bswartz> the design summit will be where the decision will happen 15:26:08 <newbism> serf with autofs 15:26:23 <bswartz> newbism: that's one proposal we 15:26:29 <bswartz> we've looked at 15:27:05 <bswartz> toabctl: we're looking at all of that, it's hard to decide where to draw the line 15:27:14 <bswartz> toabctl: thanks for the note on the etherpad 15:27:17 <newbism> looks like a good design to me. 15:27:22 <cknight> newbism: I'm not familiar with serf. If you have an idea how that could work, please follow up on the DL. 15:27:23 <newbism> im newb so you know 15:28:31 <cknight> bswartz: sounds like this topic is done for now… 15:28:35 <bswartz> yeah 15:28:41 <bswartz> okay 15:28:50 <bswartz> #topic fix for glusterfs_native breaking multibackend setups 15:28:55 <newbism> or consul.io 15:29:07 <bswartz> csaba, u_glide: what's up 15:29:42 <bswartz> I don't see a LP bug with kilo-rc-potential tag 15:29:52 <u_glide> we have patch in master https://review.openstack.org/#/c/174418/ 15:30:17 <bswartz> this is a partial fix patch 15:30:53 <vponomaryov> bswartz: it is standalone 15:30:57 <u_glide> yes, but this patch also fix another bug not opened on lp 15:30:57 <csaba1> bswartz: the bug is about policy violation, scoped to liberty 15:31:03 <bswartz> ttx: hold off on tagging RC2 please 15:31:08 <bswartz> ttx: for manila 15:31:19 <csaba1> but this patch fixes an actual behaviroal issue 15:32:17 <bswartz> okay so do we need a different bug for Kilo? 15:32:40 <u_glide> yes 15:32:58 <u_glide> csaba1: could you please create bug on lp? 15:33:00 <csaba1> yes the issue is that multibackend will be broken with glusterfs_native included 15:33:05 <csaba1> u_glide: sure 15:33:20 <bswartz> so if we backport 174418 only, that's enough to fix the issue in kilo? 15:33:52 <u_glide> yes 15:33:59 <bswartz> btw, it's really a bad idea to attach multiple commits to a bug when you're considering proposing a backport on one of the commits 15:34:10 <bswartz> it's going to make launchpad a nightmare 15:34:54 <bswartz> I supposed it's too late to untangle the existing commits and LP bug because they've merged already 15:34:57 <csaba1> u_glide: sorry, but no 15:35:23 <csaba1> u_glide: rraja just found an issue with your patch 15:35:45 <rraja> bswartz: no. i'm facing an issue where I can create 2 shares with same glusterfs volume as the backend if I use the current glusterfs_native driver in the master branch i.e. after igor's fix. 15:36:25 <bswartz> rraja: I don't understand how that affects kilo... 15:36:53 <bswartz> didn't the DB patches go in after the branch? 15:37:03 <csaba1> bswartz: it means we are still broken after the proposed inclusion of u_glide's patch 15:37:28 <csaba1> bswartz: the problem is the bug u_glide found -- after the branch... 15:37:46 <csaba1> ie. glusterfs_native breaks multibackend setups 15:37:46 <bswartz> a problem where? 15:37:59 <bswartz> that problem exists in kilo too? 15:38:46 <csaba1> in kilo, if you set up multibackend so that glusterfs_native is one of the backends, and you create a non-glusterfs-naiitve share, then m-shr will crash 15:38:56 <csaba1> yes in kilo 15:38:59 <bswartz> if there's a bug in kilo, we need to fix it in master first and propose a backport to kilo 15:39:16 <csaba1> bswartz: u_glide's patch is supposed to fix it 15:39:27 <bswartz> and you should be very careful to no mix the bug or the fix with other unrelated changes, because that makes backporting that much harder 15:39:28 <csaba1> this one: https://review.openstack.org/#/c/174418/ 15:39:54 <bswartz> csaba1: I just heard that this change is insufficient to fix the bug 15:40:30 <bswartz> rraja: do we need more than the above change to correct the issue? 15:40:31 <csaba1> sorry dropped off ,now back) 15:40:51 <bswartz> csaba1: I just heard that this change is insufficient to fix the bug 15:40:57 <rraja> bswartz: yes. 15:41:00 <csaba1> bswartz: so yes, now it turned out thaqt with u_glide's fix, something else becomes broken 15:41:21 <csaba1> so *one more* fix is needed to get the whole thing right 15:41:27 <bswartz> ugh 15:41:45 <bswartz> okay so is that one more patchset ready yet? 15:41:57 <bswartz> or if not, when will it? 15:42:10 <csaba1> rraja just diagnosed the issue, so not ATM 15:42:14 <bswartz> okay 15:42:18 <csaba1> rraja: can you fix it? 15:42:28 <rraja> csaba1: yes! 15:42:41 <csaba1> approximately when? 15:43:08 <rraja> in a day or two 15:43:18 <rraja> hopefully by tmw. 15:43:39 <bswartz> this is going to be a hard call 15:43:49 <bswartz> two days to fix + time to test and review 15:44:02 <bswartz> this puts us extremely close to the release 15:44:34 <bswartz> our alternative is to cut RC2 now (it's ready aside from this issue) and to wait until after the release to handle this backport 15:44:59 <rraja> bswartz: so if the fix gets in by today/early tmw. does it work? 15:45:12 <bswartz> also I'm not sure what the best way is to backport a bugfix that involves 2 commits 15:45:26 <bswartz> that's something I'll have to look into 15:45:41 <bswartz> we could do 2 backports or we could squash them into 1 backport 15:46:09 <vponomaryov> rraja: please, describe problem in LP bug 15:46:13 <bswartz> is it really the case that there are 2 different bugs that both need fixing? 15:46:27 <rraja> vponomaryov: sure! 15:46:36 <bswartz> or did the original change just someone fail to accomplish the fix? 15:46:45 <csaba1> bswartz: if we amend u_glide's patch and backport like that, then that's just one commit to backport 15:46:47 <bswartz> somehow* 15:47:09 <csaba1> bswartz: and on master we can merge the amendment as separarte commit 15:47:23 <bswartz> csaba1: I know we can squash them for the backport -- the question is whether that creates a mess in the history or not 15:47:27 <csaba1> but I don't think we should replicate the issue with u_glide's commit in kilo 15:47:51 <bswartz> if there are 2 different bugs here, then it's an easy decision to make 2 backports 15:48:33 <bswartz> my request is: please clearly describe both issues in LP bugs, and tag them appropriately with kilo-rc-potential 15:48:41 <csaba1> csaba1: OK so you just made th eargument why to replicate the issue with u_glide's commit in kilo -- history unambiguousness 15:48:47 <bswartz> and also please push fix second fix as soon as it's ready 15:49:25 <bswartz> I'll have to decide tomorrow whether to proceed with RC2 or to hold off 15:49:30 <csaba1> bswartz: sure 15:49:33 <bswartz> I'm willing to hold off on it today 15:49:40 <csaba1> bswartz: thanks 15:49:51 <bswartz> if we go into the weekend then I think it will be too late 15:50:27 <bswartz> and getting it into kilo means getting it merged in master first, then doing the cherry picks and re-reviewing the fixes in kilo 15:50:56 <bswartz> okay anything else on this topic? 15:51:13 <bswartz> I don't know if anyone is waiting for open discussion to raise another topic 15:51:31 <ganso_> i am 15:51:32 <bswartz> #topic open discussion 15:52:17 <bswartz> ganso_: ? 15:52:22 <ganso_> I am prototyping share migration, and I stumbled across some problems, not sure how to handle them 15:52:27 <bswartz> anyone have anything else? 15:52:35 <bswartz> ganso_: cool 15:52:36 <ganso_> I would like to ask your opinion 15:53:17 <ganso_> 1 - are share IDs allowed to change or must remain the same? in Cinder they remain the same 15:53:39 <bswartz> ganso_: actually in cinder they do some ID gymnastics 15:54:01 <bswartz> from the API client's point of view, I think it's clear that the share ID should not change 15:54:09 <bswartz> and cinder does achieve that 15:54:26 <ganso_> ok 15:54:30 <ganso_> I can achieve that too 15:54:36 <bswartz> from the DB point of view, cinder does something awkward which creates a bunch of problems for them 15:54:40 <ganso_> but for each driver it is different 15:54:53 <ganso_> for example, for generic driver, we have volume IDs which are linked to shares 15:55:03 <bswartz> I suppose we could entertain a proposal for a migration API that changes the share's ID -- but that would require careful consideration 15:55:20 <ganso_> Share ID is used as a name for the volume 15:55:40 <ganso_> I suppose some driver vendors would also have the same link in the background 15:55:45 <bswartz> ganso_: the DB changes that u_glide is working on are supposed to help solve that issue (among others) 15:55:59 <u_glide> ganso_: not anymore with https://blueprints.launchpad.net/manila/+spec/private-data-storage-api-for-drivers 15:56:15 <ganso_> yes, I read about them, and I anxious for it, because I would be able to store some additional metadata for shares 15:56:15 <vponomaryov> ganso_: it will be cahnged with implementation of BP #link https://blueprints.launchpad.net/manila/+spec/private-data-storage-api-for-drivers 15:56:28 <bswartz> forcing backends to embed manila's UUIDs in their volume/snapshot/share names ends up causing a bunch of problems, and driver private data is supposed to solve those 15:56:52 <ganso_> that would solve my problem 15:57:08 <ganso_> great :) 15:57:26 <ganso_> one other thing, is that I found out that access rules are also linked to Share ID 15:57:34 <vponomaryov> ganso_: how do you plan to handle migration w/o share servers? 15:57:46 <u_glide> ganso_: https://review.openstack.org/#/c/176877/1/manila/share/drivers/generic.py 15:57:49 <bswartz> ganso_: if you think that changing the share ID is a better idea, I'd like to see a proposal -- my instinct says it's the wrong thing but honestly I've never thought about it too much 15:58:01 <ganso_> vponomaryov: Still have not thought about "driver_handles_share_servers = false" 15:58:13 <cknight> bswartz: +1 I'm skeptical about changing share IDs 15:58:22 <vponomaryov> ganso_: + mixed one 15:58:39 <bswartz> ganso_: will you be in vancouver? 15:58:45 <ganso_> yes 15:58:48 <bswartz> this seems like a perfect topic for the summit 15:58:58 <ganso_> great :) 15:59:09 <ganso_> I look forward to meeting you guys 15:59:10 <bswartz> you'll get a lot of feedback at the summit 15:59:28 <bswartz> if you can prototype something before then, and have a WIP in gerrit, it will help the discussion even more 15:59:38 <cknight> ganso_: If you have a working prototype to demo, that would be great. 15:59:46 <ganso_> yes, that will be my final step, submitting to gerrit 15:59:52 <ganso_> I already got something working 15:59:52 <bswartz> a demo is best of all 16:00:03 <bswartz> something people can see so they don't have to imagine it 16:00:07 <bswartz> okay we're at time 16:00:08 <ganso_> but there are holes to fill in 16:00:20 <bswartz> thanks all 16:00:23 <ganso_> thanks 16:00:25 <bswartz> see you next week 16:00:31 <bswartz> #endmeeting