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