15:00:26 <bswartz> #startmeeting manila
15:00:27 <openstack> Meeting started Thu May 14 15:00:26 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:30 <openstack> The meeting name has been set to 'manila'
15:00:32 <cknight> Hi
15:00:35 <rraja> hi
15:00:36 <vponomaryov> hello
15:00:38 <markstur_> hi
15:00:39 <bswartz> hello all
15:00:39 <ganso_> hello
15:00:41 <csaba> hi
15:00:47 <weiting> hi
15:00:50 <Zhongjun> Hi
15:00:57 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:01 <u_glide> hi
15:01:18 <bswartz> last meeting before summit!
15:01:32 <toabctl> hi
15:01:41 <bswartz> in case it's not obvious, next week's IRC meeting is cancelled
15:02:07 <lpabon_phone> hi
15:04:37 <bswartz> I won't see you all in Vancouver but I will attempt to join all of the manila session remotely
15:04:37 <lpabon_phone> cool
15:04:37 <bswartz> okay first topic
15:04:37 <bswartz> #topic Whether Manila should allow to create "shares" from "snapshots" with different "share networks" or not? And why?
15:04:38 <bswartz> err
15:04:38 <bswartz> #topic Whether Manila should allow to create shares from snapshots with different share networks
15:04:38 <bswartz> I seem to be getting IRC lag, or else the bot is
15:04:39 <lpabon_phone> to discuss here or is this a session at the summit?
15:04:39 <bswartz> to discuss today
15:04:39 <vponomaryov> there is no such session
15:04:39 <bswartz> the summit sessions are finalized
15:04:40 <vponomaryov> do we have at least one backend that can support it except generic driver?
15:04:48 <bswartz> there we go!
15:05:04 <vponomaryov> support different share networks/share servers for shares created from snapshots
15:05:15 <lpabon_phone> ganesha maybe?
15:05:21 <xyang1> Hi
15:05:28 <vponomaryov> ganeshare does not support share severs
15:05:46 <vponomaryov> s/ganeshare/ganesha/
15:05:52 <bswartz> NetApp could support that, with a significant change to our driver
15:06:18 <lpabon_phone> who is asking for this feature?
15:06:18 <vponomaryov> for the moment, such possibility restricted by Manila API
15:06:36 <bswartz> I think a more interesting question to as is whether there's a valid use case for it
15:07:14 <bswartz> without that ability, your shares would be attached to their original share network forever
15:07:17 <lpabon_phone> maybe we should wait for a use case?
15:07:21 <markstur_> If we add "clone" and "migrate" then the use cases open up a bit and something like this can be done
15:07:21 <vponomaryov> bswartz: use case definitely exist - usage of separate network for cloned share
15:07:35 <bswartz> yeah I can see creating a share with a share network one day
15:09:01 <bswartz> and filling it up with data
15:09:01 <bswartz> then some time later deciding you want that share to be in a different share network
15:09:01 <bswartz> cloning it would be a reasonable way to achieve that, but only if we allow creating share in new share networks
15:09:01 <bswartz> I think this feature is something we should allow, but we need to know if it will break any drivers that currently support share servers
15:09:46 <lpabon_phone> we probably need to put that on the mailing list
15:10:02 <xyang2> bswartz: without changes in the current driver, it will likely to break it
15:10:15 <bswartz> xyang isn't here
15:10:27 <xyang2> bswartz: I know
15:10:39 <vponomaryov> =)
15:10:43 <xyang2> bswartz: just saying drivers need to be modified to support it
15:11:54 <vponomaryov> xyang2, bswartz: so, we have only driver-update restriction, and backends do support such case?
15:12:25 <vponomaryov> like creation of additional logical interfaces for vservers in case of netapp driver?
15:14:31 <lpabon_phone> I have to check with csaba to see how this would affect gluster drivers
15:15:01 <vponomaryov> lpabon_phone: nohow, because share servers are not supported with gluster drivers
15:15:21 <vponomaryov> lpabon_phone: hence, none of share networks will be used
15:16:53 <bswartz> hi
15:16:58 <bswartz> is anyone still here?
15:17:02 <vponomaryov> yes
15:17:02 <u_glide> yes
15:17:06 <ganso_> yes
15:17:06 <xyang2> yes
15:17:10 <bswartz> okay apparently I was just talking to myself for 5 minutes
15:17:21 <bswartz> don't know why IRC is acting funny
15:17:22 <vponomaryov> nice
15:17:44 <bswartz> what was the last thing that came through?
15:17:57 <toabctl> 17:10:15 bswartz xyang isn't here
15:17:57 <vponomaryov> (18:10:14) bswartz: xyang isn't here
15:18:04 <bswartz> okay
15:18:08 <bswartz> then I noticed she is
15:18:11 <xyang2> :)
15:18:13 <bswartz> xyang1: do you have any idea if this feature could be supported on your drivers?
15:18:25 <bswartz> markstur_: clone is something we want to add, but it would be defined as semantically equivalent to: create snapshot, create share from snapshot, delete snapshot -- just more efficient
15:18:28 <xyang2> bswartz: I'll have to check
15:18:47 <bswartz> okay
15:18:58 <bswartz> vponomaryov: let's start a ML thread on this topic
15:19:10 <vponomaryov> ok
15:19:21 <bswartz> I think we should do it, and give any driver maintainers a chance to figure out if they can or can't implement it
15:19:34 <bswartz> and discuss on the ML
15:19:48 <bswartz> if nobody replies, then we can just go ahead and make the API more flexible
15:20:09 <xyang2> bswartz: sounds good, I'll investigate
15:20:55 <bswartz> if/when we do implement it, we should make sure that any problems created get bugs filed so we can track if all drivers implement it correctly by the end of the release
15:21:17 <bswartz> there's a lot of time left though, so this is a great time to try something new
15:21:24 <bswartz> okay next topic
15:21:35 <bswartz> #topic Share extend - disruptive operation?
15:22:10 <bswartz> so we discussed share resize (extend and shrink) at the midcycle, and u_glide has been doing implementation of the extend part
15:22:34 <u_glide> #link https://review.openstack.org/#/c/182383/
15:22:39 <bswartz> we noticed that some backends can resize a share without causing disruptions, but others might only be able to do it disruptively
15:23:06 <bswartz> I wanted to discuss how we should handle this
15:23:32 <bswartz> do we just document that extending a share may cause a brief loss of connectivity?
15:24:15 <ganso_> bswartz: Shouldn't mount automation mitigate this problem?
15:24:25 <bswartz> ganso_: no
15:25:13 <xyang2> bswartz: we should probably disable it by default so that user is aware of it?
15:25:21 <bswartz> many backends will implement a share size as simply a quota value
15:25:44 <bswartz> changing a quota value doesn't need to disrupt client access to their share, and it shouldn't in those cases
15:26:14 <vponomaryov> generic driver does not satisfy such criterion
15:26:35 <bswartz> yes, generic is one driver that needs to do some disruptive changes to alter the share size
15:27:11 <bswartz> I'm not sure how many other there are
15:27:55 <bswartz> If most drivers can do this non disruptively, then I feel comfortable just documenting that certain drivers may cause brief outage during share resize
15:28:21 <bswartz> if a majority are going to have problems though, then we should take more care
15:28:54 <bswartz> this might be another case where we need to poll driver maintainers on the ML
15:30:04 <bswartz> xyang2: I don't like disabling it by default because it kind of defeats the value of adding the feature
15:30:29 <bswartz> resize is something users should be able to rely on having access to
15:30:34 <xyang2> bswartz: ok, I think we have to the results of the poll
15:30:39 <bswartz> at least resizing larger
15:30:52 <bswartz> resizing smaller is always trickier
15:31:02 <bswartz> so that may be a truly optional feature
15:31:13 <xyang2> bswartz: resize larger is usually not a problem.  do we want support shrinking too?
15:31:36 <bswartz> xyang2: I think we should introduce shrink as an optional driver feature
15:31:45 <bswartz> it's valuable and many drivers can support it
15:31:56 <xyang2> bswartz: ok
15:31:57 <bswartz> but there may be some where it's near impossible, so it makes more sense to make it optional
15:32:19 <bswartz> I'm pretty sure everyone can increase size, even if it's disruptive operation only
15:32:44 <bswartz> okay and one last topic from me
15:32:50 <bswartz> #topic 3rd party vendor CI
15:32:56 <bswartz> #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/064086.html
15:33:12 <bswartz> I started a ML thread yesterday
15:33:33 <bswartz> that is my proposal for how we should do 3rd party vendor CI
15:34:02 <bswartz> the TLDR version is that by liberty-rc1 all the drivers would need working CI system, similar to cinder
15:34:07 <bswartz> otherwise we would remove the drivers
15:34:42 <bswartz> I'm open to debate on the specifics -- I don't want the mandate to come from me only, I want the community to agree on what we want
15:35:29 <bswartz> please respond to the ML thread soon though if you have an opinion
15:36:19 <bswartz> I'd like to have the plan agreed to by the summit next week so we can tell people what they need to do during liberty
15:36:33 * bswartz wonders if his IRC connection is acting up again
15:36:43 <toabctl> bswartz: works :)
15:36:44 <vponomaryov> its alive
15:36:44 <ganso_> no, it is not :)
15:36:46 <bswartz> ok
15:36:50 <bswartz> y'all are so quiet...
15:37:04 <markstur_> just waking up
15:37:27 <bswartz> so I won't review the whole plan here, please read it though
15:37:36 <bswartz> I proposed several intermediate deadlines
15:37:52 <bswartz> if we agree on them, I'll start implementing them after summit
15:37:58 <xyang2> bswartz: one suggestion I have is to publish the list of driver status early
15:38:19 <xyang2> bswartz: don't do it on the day of removal:)
15:38:29 <bswartz> xyang2: yeah I don't plan to keep anything secret
15:39:01 <bswartz> that was one thing mike did that I didn't agree with
15:39:04 <toabctl> we could track the progress and responsible persons on a wiki page or so
15:39:17 <xyang2> wiki sounds good
15:39:22 <bswartz> step one is to list the drivers that will need CI and get contact info for the maintainers
15:39:37 <bswartz> once we have that, we can keep all relevant details about them on the same wiki
15:40:01 <bswartz> so if anyone is NOT meeting deadlines, we can simply note it there and there won't be any surprises
15:40:02 <markstur_> Might need to clarify how this affects new drivers getting merged while working on CI, or not.
15:40:12 <xyang2> I know there is already a 3rd party wiki, but we should still have one for manila ourselves
15:40:15 <bswartz> markstur_: good point I didn't consider that
15:40:43 <bswartz> my first instinct is to say that any new driver is subject to the same requirements
15:40:55 <bswartz> even if the driver itself doesn't merge until the week before L-3
15:41:14 <vponomaryov> bswartz: what about drivers that do not support required features?
15:41:26 <vponomaryov> bswartz: it should be nailed before
15:41:27 <xyang2> vponomaryov: that is a good question
15:41:35 <bswartz> if the new driver doesn't have CI by rc1 we would just remove it until it does
15:41:38 <xyang2> do we have minimal requirements
15:41:47 <bswartz> vponomaryov: another excellent point
15:42:34 <bswartz> so we will need to define the minimum features, and make sure those are covered by tempest tests -- then the tempest tests become the qualification suite that decides if the driver supports the features or not
15:42:46 <cknight> bswartz: +1
15:42:52 <bswartz> and features that are defined to be optional must have tempest tests that can be skippable
15:43:18 <u_glide> and we should  clean up contrib dir in manila api
15:43:31 <xyang2> bswartz: and define them clearly in the wiki
15:43:33 <bswartz> u_glide: yes that's a topic for the design summit
15:43:46 <bswartz> at least the mechanism is, not defining the minimum feature set
15:44:05 <bswartz> I think defining the minimum feature set will be a topic for after the summit
15:44:25 <cknight> bswartz: we can set up a wiki listing minimum driver features.  Cinder has one:  https://wiki.openstack.org/wiki/CinderSupportMatrix
15:44:34 <bswartz> cknight: yes
15:44:42 <xyang2> cknight: +1
15:44:47 <toabctl> +1
15:44:58 <vponomaryov> u_glide: +1, all reguired features should be "core" APIs in manila
15:44:59 <bswartz> cknight: fwiw the cinder team doesn't like that wiki though -- they wish there was a page that was automatically generated
15:45:29 <bswartz> because it's possible to lie on a wiki page
15:46:12 <bswartz> okay so please add those notes to the ML thread
15:46:16 <bswartz> about new drivers and about minimum features
15:46:52 <bswartz> #topic open discussion
15:47:01 <bswartz> anything else?
15:47:02 <cknight> Summit etherpads are linked for the Manila sessions.
15:47:08 <cknight> #link https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Manila
15:47:10 <bswartz> oh yes
15:47:40 <bswartz> I'll add some notes to all of these
15:47:51 <bswartz> thank cknight for creating them
15:48:05 <toabctl> there is the CrossProjectLiaisons
15:48:11 <toabctl> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons
15:48:26 <xyang2> cknight: YVR?
15:48:30 <bswartz> btw since we will have some people remote during the design summit (including me) capturing notes in the etherpad will be very important
15:48:41 <bswartz> YVR = vancouver airport code
15:48:44 <cknight> xyang1: Not my choice, *all* etherpads have that.
15:48:51 <xyang2> ok
15:48:51 <bswartz> it seems to be the convention everyone is using
15:49:20 <bswartz> toabctl: what about cross project liasons?
15:49:34 <toabctl> bswartz: the fields for manila are empty
15:49:35 <bswartz> toabctl: would you like to volunteer?
15:49:51 <toabctl> bswartz: I wanted but I can't attend the oslo meetings at monday.
15:49:56 <bswartz> I know you've done a bunch of great work increasing our integration with oslo
15:50:40 <bswartz> how essential are the monday meetings?
15:51:12 <bswartz> I don't think anyone will be attending those meetings from Manila if you aren't
15:51:31 <toabctl> bswartz: no idea. If nobody complains I can add myself to the oslo list
15:51:45 <toabctl> even without attending the oslo meetings.
15:51:58 <bswartz> toabctl: I'd be happy for you to be the liason -- I can't think of a better candidate
15:52:24 <toabctl> bswartz: ok. great
15:52:48 <cknight> toabctl: Thanks!
15:53:06 <bswartz> toabctl: hopefully you know someone who can fill you in on those meetings if you have to miss them
15:53:52 <bswartz> cross project concerns are very important and we have a challenge being such a distributed team -- we don't all get as plugged into other projects or to the conferences in general
15:54:12 <bswartz> It's all I can do to stay on top of what's going on in Cinder and Manila
15:54:40 <bswartz> okay any last things
15:55:04 <csaba> bswartz: can I bring up our kilo backport case?
15:55:16 <bswartz> csaba: sure
15:55:18 <csaba> https://bugs.launchpad.net/manila/+bug/1447692
15:55:18 <openstack> Launchpad bug 1447692 in Manila "glusterfs_native breaks multibackend" [High,Triaged] - Assigned to Ramana Raja (rraja)
15:55:33 <csaba> recall it's special in two ways:
15:56:11 <bswartz> csaba: I thought there were 2 patchsets
15:56:11 <csaba> -that the fix should be backported is known but it was held back because of an issue we thought there is with the fix
15:56:37 <csaba> -the fix for this one was submitted for another bug
15:56:52 <bswartz> "n issue we thought there is" -- was that assessment wrong?
15:57:17 <bswartz> when this fix went into master we decided not to backport it because there was still a problem with it
15:57:24 <csaba> this is the fix: https://review.openstack.org/#/c/174418/ and this is the bug we thought we intereferes: https://bugs.launchpad.net/manila/+bug/1448029
15:57:24 <openstack> Launchpad bug 1448029 in Manila "glusterfs_native: able to create multiple shares with identical glusterfs volume as backend" [Undecided,Invalid]
15:57:35 <csaba> now that bug is resolved to invalid
15:57:48 <csaba> bswartz: yes
15:58:13 <csaba> so that problem is moot, so the backport can get a green light
15:58:33 <bswartz> okay so your proposal is to backport the one change and we can expect that to solve all issues related to glusterfs in kilo with and without multibackend?
15:59:04 <csaba> )on the bug entry, comment https://bugs.launchpad.net/manila/+bug/1447692/comments/1 refers to the fix)
15:59:04 <openstack> Launchpad bug 1447692 in Manila "glusterfs_native breaks multibackend" [High,Triaged] - Assigned to Ramana Raja (rraja)
15:59:15 <csaba> bswartz: exactly
15:59:26 <bswartz> have you already pressed the cherry pick button?
15:59:43 <bswartz> if not, go ahead and we'll review it for stable/kilo
15:59:53 <csaba> bswartz: I have not yet heard of the cherry pick button :)
15:59:59 <csaba> you mean it's agerrit feature?
16:00:00 <bswartz> I've already sent a note out to core team members about what the requirements are for merging something into the stable branch
16:00:25 <bswartz> csaba: log into gerrit, it's right next to the review/revert/abandon buttons
16:00:41 <bswartz> that's the "easy button" way to backport stuff
16:00:50 <bswartz> okay we're out of time
16:00:54 <csaba> ah OK, thanks, I'll do...
16:01:01 <bswartz> I wish all of you safe travels if you're headed to vancouver
16:01:06 <cknight> bswartz:  +1
16:01:13 <bswartz> we will meet up on IRC in 2 weeks
16:01:18 <cknight> See everyone there.
16:01:23 <toabctl> see you
16:01:25 <bswartz> expect some more ML traffic related to the other 2 topics from this meeting
16:01:36 <bswartz> thanks everyone
16:01:46 <bswartz> #endmeeting