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