15:00:14 <bswartz> #startmeeting manila
15:00:15 <openstack> Meeting started Thu Jul 23 15:00:14 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:16 <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:23 <bswartz> hello all
15:00:24 <ganso_> hello
15:00:28 <csaba> hi
15:00:29 <markstur> hi
15:00:34 <xyang1> Hi
15:00:52 <vponomaryov> hi
15:01:04 <zhongjun2> hi
15:01:28 <bswartz> #agenda https://wiki.openstack.org/wiki/Manila/Meetings
15:01:31 <toabctl> hi
15:02:19 <bswartz> #topic midcycle meetup
15:02:27 <bswartz> #link https://etherpad.openstack.org/p/manila-liberty-midcycle-meetup
15:02:35 <bswartz> so it's just 1 week away!
15:03:30 <bswartz> right now the number of attendees on the etherpad looks small enough that a google hangout should accommodate everyone
15:03:46 <bswartz> unless a bunch of people show up who didn't add their names
15:04:03 <bswartz> so I will setup the hangout and post the link
15:05:23 <bswartz> based on the proposed topics, I think we won't use the full 8 hours both days
15:05:53 <bswartz> we can probably end early, so those of you in europe don't have to stay up too late
15:06:43 <bswartz> I still plan to put a schedule together with timeslots for the various topics
15:06:47 <csaba> bswartz: it's early in Europe but we can think of compassionately to our Indian friends..
15:07:21 <bswartz> csaba: with a remote meetup there's always a geography that gets screwed
15:07:54 <bswartz> in our case it's california+pacific+asia
15:08:00 <bswartz> that's just due to where the core team is
15:08:11 <csaba> bswartz: yes I know
15:08:15 <vponomaryov> mkoderer: are you aware about meetup?
15:08:34 <vponomaryov> mkoderer: want to pull up topic with tempest plugin?
15:09:33 <bswartz> oh yeah that would be a great topic for the meetup
15:09:39 <bswartz> if mkoderer can attend
15:10:55 <bswartz> anyways there's a reminder on the ML now and I'll be handling the video/audio
15:11:12 <bswartz> expect a schedule with timeslots for the topics (which we will adhere to loosely)
15:11:44 <bswartz> I'll make it clear when I post a schedule that we might run early or late
15:12:10 <bswartz> oh and, obviously there won't be an IRC meeting next week due to the meetup
15:12:23 <bswartz> I'll update the wiki to reflect that
15:12:46 <bswartz> #topic CI deadline for L-2
15:13:01 <bswartz> L-2 is next week
15:13:11 <kaisers_> Hi
15:14:07 <bswartz> in fact the milestone overlaps with the midcycle, so if there is any code that needs discussion before merging in L-2 we could use the meetup to cover it
15:14:50 <vponomaryov> bswartz: do we have some desicion about versioned objects?
15:14:54 <bswartz> if you haven't heard from me yet about CI, expect an email
15:15:05 <vponomaryov> bswartz: we have in gerrit some commits according to it
15:15:13 <bswartz> vponomaryov: let's make that the next topic
15:15:17 <bswartz> I want to finish CI
15:15:23 <vponomaryov> ok
15:15:53 <ganso_> CI has a deadline for L-2, and another deadline for L-3, correct?
15:16:18 <bswartz> just to remind everyone, by L-2 we expect all driver maintainers to have their CI account and they should be in the progress of getting the system working
15:16:37 <kaisers_> Ack
15:16:43 <zhongjun2> I want to discussion about huawei-driver-support-dedup-compression blueprint.
15:17:03 <bswartz> those that aren't posting results yet must have tempest running on their backends and must be able to share log of a tempest on their backend
15:17:05 <cFouts> ./
15:17:30 <bswartz> if you have any tempest tests failing, you must have bugs filed in LP
15:18:10 <bswartz> the L-3 deadline involves the CI system posting on changes, and if you haven't made progress on getting your system working, you probably won't meet the L-3 deadline
15:18:17 <vponomaryov> bswartz, csaba: in that case gluster driver just can not pass tempest apriori
15:18:35 <vponomaryov> because of unskipable 'snapshot' tests
15:18:51 <bswartz> vponomaryov: gluster doesn't do snapshots?
15:19:28 <csaba> vponomaryov, bswartz : not at the moment, we are working towards that
15:19:36 <vponomaryov> bswatz; no, #link https://github.com/openstack/manila/blob/4dbe4294/manila/share/drivers/glusterfs.py#L409
15:19:38 <bswartz> csaba: will it happen by L-3?
15:19:41 <kaisers_> That is a topic for Quobyte, too
15:19:56 <csaba> bswartz: yes
15:20:17 <vponomaryov> csaba: share craetion from snapshot too?
15:20:24 <csaba> bswartz: we don't have a dedicated bp but this bp: https://blueprints.launchpad.net/manila/+spec/modular-glusterfs-share-layouts will imply that
15:20:27 <bswartz> we've discussed the snapshot requirement a few times -- my stance is that you don't need to have an efficient implementation, but it does need to meet the snapshot semantics for us to call it a manila driver
15:21:06 <bswartz> snapshots are part of the manila API and if you can't implement them you can't provide manila users a reasonable experience
15:21:07 <csaba> vponomaryov: yes, that will be added too soon
15:21:24 <bswartz> does anyone disagree with that statement? are there any in favor of allowing snapshot-less drivers?
15:21:48 <kaisers_> I haven't gone far into that so far. But we'll check what we can do about that.
15:21:49 <vponomaryov> huawei
15:21:55 <vponomaryov> does not have snapshots too
15:21:59 <bswartz> (just a note: we allowed some snapshotless driver in previous releases with the understand that snapshots were going to be implemented later)
15:22:18 <cknight> bswartz: Snapshots seem like a reasonable minimum requirement.
15:22:21 <lpabon> i think we need to be more specific, which glusterfs driver csaba do you need to work on to support snapshots?
15:22:35 <bswartz> I won't hold it against anyone who disagrees but as a community we have to reach a common understanding
15:22:39 <vponomaryov> correction: huawei driver does not have creation of a share from snapshot
15:22:40 <lpabon> and which driver has it already
15:22:45 <toabctl> vponomaryov: is huawei working on snapshot support?
15:22:56 <rraja> lpabon: glusterfs_native driver supports snapshots and glusterfs (NFS) driver does not.
15:23:00 <csaba> lpabon: vponomaryov was specific, the gluster driver does not have create_snapshot
15:23:10 <vponomaryov> toabctl -> zhongjun2
15:23:23 <csaba> lpabon: create_from_snapshot is not supported by either gluster* driver ATM
15:23:32 <lpabon> ok, cool
15:24:22 <bswartz> I suggest that all of the drivers that can't implement snapshots properly might want to get together and see if there's a common mechanism they can use to emulate snapshots well enough to support the API
15:24:36 <kaisers_> I do see the use of snapshot but I'm not sure about them being a req. for shared volumes in Manila.
15:24:39 <kaisers_> Ok
15:24:55 <bswartz> data copying might be involved, but that's okay
15:24:55 <zhongjun2> Huawei is not support create_from_snapshot now.
15:25:20 <kaisers_> Ideas about where to find previous discussions? I'll read that...
15:25:27 <vponomaryov> zhongjun2: what plans do you have about it?
15:25:57 <lpabon> is there a time limit for create_from_snapshot api?
15:25:59 <zhongjun2> but I will support create_from_snapshot use another method.
15:26:16 <csaba> lpabon: L3
15:26:39 <lpabon> no, i mean, in the API itself, once the request is being process, is there a timeout
15:26:48 <bswartz> lpabon: you can't pass the tempest tests without snapshots working
15:26:50 <csaba> lpabon: ah OK
15:27:03 <bswartz> oh, no
15:27:10 <lpabon> ah, ok, that helps
15:27:17 <bswartz> snapshots can take time proportional to the size of the share
15:27:28 <cknight> lpabon:  The semantics of the API must work, but inefficient copies are OK if that's all you can do.
15:27:34 <bswartz> it's not ideal but at least it works
15:27:47 <zhongjun2> not implement on array. Mount new share and snapshot to host, and then data copy from snapshot to new share.
15:27:50 <lpabon> yeah, cool.  baby steps :-)
15:28:49 <bswartz> we have a topic about minimum features at the midcycle
15:29:04 <bswartz> I'm sure snapshots will be the center of discussion there
15:29:40 <vponomaryov> bswartz: maybe we need to create some map with features and its support in drivers?
15:29:55 <bswartz> please come with helpful suggestions
15:30:04 <bswartz> vponomaryov: yes that would be great if we had that
15:30:09 <u_glide2> vponomaryov: +1 in documentation
15:30:17 <zhongjun2> +1
15:30:19 <ganso_> vponomaryov: +1
15:30:50 <bswartz> vponomaryov: would you like to create an empty map and we can ask driver maintainers to fill it in before the meetup?
15:31:08 <vponomaryov> bswartz: sure
15:31:23 <bswartz> thanks
15:31:41 <vponomaryov> I will fill it with values for Generic driver
15:31:42 <bswartz> okay anything else about CI?
15:32:01 <bswartz> I'm hearing that snapshot support is a sticking point for the CI requirement, but aside from that, any issues?
15:32:27 <bswartz> anyone need help and not getting it?
15:33:00 <bswartz> okay
15:33:09 <bswartz> #topic versioned objects
15:33:18 <bswartz> vponomaryov: what did you want to discuss about this?
15:33:39 <vponomaryov> bswartz: first get know, do we have any desicion about it?
15:34:01 <vponomaryov> bswartz: like implement but after some feature appears, or implement anytime
15:34:20 <bswartz> vponomaryov: we haven't discussed it recently
15:34:22 <vponomaryov> bswartz: no do not implement at all
15:34:53 <bswartz> is there a gerrit change still in review?
15:34:59 <cknight> bswartz: yes
15:35:03 <vponomaryov> bswartz: ьщку ерфт щту
15:35:07 <vponomaryov> bswartz: more than one
15:35:54 <u_glide2> we wait for  appearance of indirection api https://review.openstack.org/#/c/176654/1/specs/liberty/indirection-api.rst
15:36:19 <cknight> bswartz: This is something we may need, but IMO we have other things to focus on for Liberty.
15:36:20 <u_glide2> in oslo lib
15:36:28 <bswartz> vponomaryov: I added a topic for midcycle meetup because we should discuss it again
15:36:35 <cknight> bswartz: Same goes for API microversions.
15:36:50 <cknight> bswartz: (Which we can discuss next week if you like.)
15:37:14 <u_glide2> +100 to API microversions in liberty
15:37:43 <bswartz> well microversions has huge obvious advantages
15:38:18 <bswartz> versioned objects has advantages but it seems there are alternatives
15:38:33 <cknight> I had microversions ported to Manila before the last summit, but the working session rooms weren't conducive to a demo.
15:38:42 <cknight> I can do that next week if y'all want.
15:39:02 <bswartz> Let's talk about both
15:39:02 <u_glide2> cknight: +1
15:39:15 <cknight> bswartz: OK, I'll add microversions to the agenda.
15:39:20 <vponomaryov> u_glide2: where is additional 99 ? =)
15:39:26 <bswartz> cknight: already done
15:39:35 <cknight> bswartz: I see that :-)
15:39:42 <u_glide2> vponomaryov: +99 to actual implementation in gerrit :)
15:40:10 <bswartz> okay
15:40:15 <bswartz> #topic open discussion
15:40:19 <bswartz> anything else?
15:40:27 <zhongjun2> I have a question about one blueprint. link:https://review.openstack.org/#/c/197413/
15:40:27 <bswartz> I wanted to ask about the instability in the gate
15:40:43 <zhongjun2> We all have the same capability, How about we consisitent the capabilities of dedup and compression,
15:40:44 <zhongjun2> use capabilities:dedup='<is> true'. The CapabilityFilter can choose backend in netapp, huawei, or the vendor of support this capabilities.
15:41:00 <u_glide2> Share Instance is ready for review https://review.openstack.org/202486/
15:41:00 <u_glide2> Folks, please go ahead! :)
15:41:05 <bswartz> zhongjun2: yes
15:41:13 <cknight> u_glide2: working on it…
15:41:14 <bswartz> zhongjun2: this is an area where cinder has struggled
15:41:26 <markstur> Yes for common capabilities
15:41:34 <bswartz> zhongjun2: ideally we should agree on capability names for things that really are the same
15:41:39 <bswartz> and document those common capabilities
15:41:49 <markstur> Do we need to distinguish backends that support dedup from backends that  imply dedup is on?
15:42:08 <markstur> Same with thin_support is it enabled or an option
15:42:47 <bswartz> markstur: if a backend has dedup always-on then it should advertise the capability
15:42:51 <markstur> For vendor-scoped it is easy, but for common capabilities we might need taht clarified
15:43:17 <markstur> bswartz, Good.  But capabilities:dedup or capabilities:dedup_enabled
15:43:24 <bswartz> it's up to the admin to decide if he care about making dedup something that is a value-added feature
15:43:39 <bswartz> if none of the share_types have a dedup extra spec it won't matter
15:43:59 <bswartz> and I seriously doubt anyone would put dedup=False in a share_type extra spec
15:44:13 <markstur> Yeah.  So maybe just "dedup" is enough
15:44:29 <bswartz> markstur: yeah that's what we need to agree on and document
15:44:56 <markstur> So would netapp drop the scoped dedup and just do it whenever it is a capability?
15:45:00 * bswartz added another meetup topic
15:45:15 <markstur> bswartz, was already there (kinda)
15:45:21 <bswartz> markstur: we'd most likely to both, just to maintain backwads compatibility
15:45:26 <vponomaryov> bswartz: "Common capabilities" duplicated
15:45:31 <bswartz> there's no harm in having multiple capabilities that mean the same thing
15:45:33 <vponomaryov> it is already there
15:45:47 <bswartz> vponomaryov: already where
15:45:54 <markstur> there is harm in duplicate agenda items
15:45:55 <vponomaryov> in topic list
15:46:06 <markstur> :)
15:46:12 <vponomaryov> bswartz: lines 31-33
15:46:38 <bswartz> oh doh
15:46:46 * bswartz fails to read
15:46:49 <bswartz> thanks
15:46:53 <vponomaryov> ))
15:47:09 <zhongjun2> How about review this bp link:https://review.openstack.org/#/c/197413/ and Discussion in bp too?
15:47:40 <bswartz> zhongjun2: we don't really do discussion in BPs -- usually its in these meetings or in gerrit reviews
15:47:53 <bswartz> but we will get to that code review
15:48:13 <bswartz> u_glide2's is top of my list
15:48:24 <bswartz> so my question was about gate instability
15:48:44 <bswartz> aside from the mock issues that we've been hit with, do we have any randomly failing tests still?
15:49:15 <vponomaryov> bswartz: yes, there is some
15:49:31 <bswartz> vponomaryov: which tests?
15:49:53 <vponomaryov> bswartz: today I saw several times that "extend share" in tempest failed
15:50:08 <vponomaryov> bswartz: because of error in "device attach" in Nova
15:50:20 <bswartz> was there a nova change that causes it?
15:50:21 <vponomaryov> bswartz: looks like retry did not help
15:50:29 <kaisers_> 've got to go, bye
15:50:31 <bswartz> or is it probably a test bug?
15:50:35 <vponomaryov> bswartz: it is unstable error - couple of times for a day
15:51:12 <vponomaryov> also kaisers_'s suffer from instability greatly =)
15:51:18 <bswartz> as we make CI requried we need to make sure that the tests themselves don't have weird race conditions that cause problems, and we need to prioritize fixing broken tests
15:51:18 <vponomaryov> kaisers_'s commit
15:51:29 <bswartz> okay
15:52:08 <u_glide2> bswartz: in extend share case we have race conditions in cinder/nova
15:52:44 <bswartz> why can't we work around those
15:53:22 <bswartz> if cinder extend is itself broken that's a whole other issue
15:53:42 <bswartz> but the test should make it possible for well-written drivers to pass all the time
15:54:24 <bswartz> okay well that's all I had
15:54:30 <vponomaryov> bswartz:well-written drivers can skip "extend" feature" and do not have such "great" dependency as "very" stable Nova + Cinder =)
15:55:04 <bswartz> vponomaryov: okay that's another discussion
15:55:07 <bswartz> thanks everyone
15:55:15 <bswartz> see you next week at the meetup
15:55:26 <bswartz> #endmeeting