16:00:23 #startmeeting cinder 16:00:24 Meeting started Wed May 7 16:00:23 2014 UTC and is due to finish in 60 minutes. The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:27 The meeting name has been set to 'cinder' 16:00:33 hey everyone 16:00:33 o/ 16:00:36 o/ 16:00:36 hi 16:00:38 hi 16:00:39 Hey 16:00:40 hello 16:00:52 * jgriffith feels like he's been gone forever 16:01:04 hello 16:01:07 *agrees* 16:01:16 agenda: https://wiki.openstack.org/wiki/CinderMeetings 16:01:29 We've got one item listed by thingee 16:01:35 yay 16:01:46 #topic limt==0 patch: https://review.openstack.org/#/c/86207/ 16:01:51 Hello all. 16:01:56 so I agree with your jgriffith 16:02:05 your comment, jgriffith * 16:02:17 cool 16:02:21 done 16:02:22 :) 16:02:25 haha 16:02:28 ez-pz 16:02:31 I agree too 16:02:39 does that address the issue of why snapshots and volumes behave differently? 16:02:42 Ok... now this is just weird 16:02:45 we're all agreeing 16:02:50 quick somebody protest 16:02:56 I disagree 16:03:01 bswartz: thank you sir 16:03:05 np 16:03:08 whatever behavior is correct it seems like it shouldn't be different for snaps vs volumes... 16:03:09 morning 16:03:10 bswartz: I'm going to ignore you of course 16:03:25 eharney: one is using sqlalchemyutils, other is relying on the common api code 16:04:01 eharney: Yes, that sounds like a simple bug... all of them shoudl do 0 === max_limit 16:04:08 eharney: they should all be consistent IMHO 16:04:11 DuncanT: +1 16:04:14 jgriffith: +1 16:04:18 low hanging fruit 16:04:22 yes 16:04:23 sounds good then 16:04:25 I follow up on the bug 16:04:26 kk 16:04:28 I'll* 16:04:34 0 just makes no sense to me 16:04:45 I mean 0 --> list nothing 16:04:49 seems kinda silly 16:05:06 anybody have anything else they're dieing to talk about? 16:05:19 any big plans for the next week? 16:05:20 :) 16:05:24 people should pitch in on etherpads 16:05:37 #topic summit sessions 16:05:47 https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Cinder 16:06:07 thingee: thanks 16:06:20 thingee: so note I created an etherpad for each session but no data in it 16:06:24 other than title/time 16:06:40 if you have a session and want to pre-seed it with stuff you should get on it 16:07:17 I think I got what I wanted 16:07:33 anybody have any questions about sessions? 16:07:52 does the etherpad session mean there is a scheduled session for said topic? 16:08:12 glenng: http://junodesignsummit.sched.org/ 16:08:29 Haven't made it through the conf sched yet. Mgr wants to see work out of me ;-) 16:08:34 cinder sessions are in baby blue 16:09:12 Yes. Understood. I had just noticed an etherpad session on NFS and wondered if a conf session was in place for that. 16:09:14 Doh! So many Friday sessions!@ 16:09:38 jungleboyj: welcome to Cinder design summit 16:09:49 jungleboyj: we always get Thurs afternoon and Friday 16:10:19 glenng: you talking about "NFS and its role within Cinder" 16:10:28 jgriffith: Yes sir. 16:10:32 :-( Ok. I think my flight is pretty late afternoon Friday. 16:10:37 jgriffith: I prefer thurs and friday 16:10:42 glenng: yeah, that's bswartz 's scheduled session 16:10:46 jgriffith: glenng and I will both be presenting 16:10:46 people are dead tired then 16:10:46 thingee: me too actually 16:10:49 to argue 16:10:55 hehe 16:11:03 :-) 16:11:06 haha... it's actually good because I typically learn alot M-Thur 16:11:21 well except use cases like disaster recovery and having replications on different planets 16:11:30 :) 16:11:47 How to brew British beer ;-) 16:11:54 Mmmm, beer 16:11:55 Ok... anything we need to plan ahead of next week? 16:12:07 anything people think was missed? 16:12:21 special considerations we need to be sure and talk about etc? 16:12:22 * coolsvap missed summit 16:12:31 LIO 16:12:43 thingee: ahhh... yes 16:12:47 #topic LIO 16:12:50 I can't make head nor tail of https://blueprints.launchpad.net/cinder/+spec/cinder-volume-metadata-for-backup-restore 16:13:06 one thing we've talked about the past release is making the LIO driver the default tgt 16:13:17 this provides some flexibility and typically better performance 16:13:30 IIRC it also lets us do some work with Fibre Channel as well 16:13:42 it could potentially push fabric knowledge out of cinder. 16:13:45 we can start making some of that code more "common" 16:13:52 :) 16:13:53 thingee: I would LOVE that 16:14:01 jgriffith: +100000000000 16:14:09 any objections to moving forward on that? 16:14:17 So there is a problem with virsh and FC currently 16:14:20 FYI 16:14:27 hemna: surprise surprise 16:14:37 the only concern i have about it being default is how to handle platforms that don't support it sensibly 16:14:37 hemna: I still say FC is a horrible technology for OpenStack 16:14:38 virsh can't do HBA passthrough to the guest os's 16:14:47 eharney: +1 16:14:53 but we have that same issue w/ tgtd. so... need to think about it anyway 16:14:54 I'm curious to know how LIO helps cinder not worry about fabric stuff 16:15:00 eharney: interesting 16:15:03 also fabric code can't completely be removed from cinder. tgt still needs it :( 16:15:08 eharney: I don't have info on that 16:15:14 eharney: thingee care to enlighten? 16:15:20 jgriffith: well it's simple from my side. el6 == only tgtd. el7 == only LIO 16:15:28 ahhh 16:15:29 thingee, cinder still needs it for initiator side of things and LUN discovery (brick initiator) 16:15:34 eharney: dang RHEL!!! 16:15:35 which leads me toward wondering about default = prefer LIO but fallback 16:15:44 eharney: that's what I'd propose 16:15:45 but i dunno what the best way is to handle all that or if we just leave it up to config 16:15:53 eharney: that's what I did with iet/tgt 16:15:59 ahh yeah, before my time :) 16:16:03 config is probably fine as well 16:16:16 doesn't seem unreasonable to me at least 16:16:25 great 16:16:29 so a first step... 16:16:42 LIO packages are a mess in upstream packages 16:16:53 If we're supporting a fallback, can we get the gate to test both? 16:17:06 there was a fork of some of the initial rtslib code and distros like ubuntu are broken because they confuse the two 16:17:07 DuncanT: good idea 16:17:15 DuncanT: we'll have to look into that 16:17:17 thingee: ah yes 16:17:29 #note investigate gating on tgt and lio 16:17:35 as a RHEL consumer I want to make sure that we can configure it. :-) 16:18:01 for reference https://bugs.launchpad.net/ubuntu/+source/rtslib/+bug/1166042 16:18:03 Launchpad bug 1166042 in rtslib "rtslib-fb is not object compatible with rtslib" [High,Fix released] 16:18:04 * coolsvap already investigating 16:18:16 eharney: can you get LIO on RHEL through epel? 16:18:31 jgriffith: pretty sure the kernel support isn't there for el6 16:18:42 jgriffith: I have done that on el7 16:18:47 eharney: doh! 16:18:51 coolsvap: yeah el7 is fine 16:19:00 thingee: interesting... rtslib and rtslib-fb aren't compatible so naming like that is scary 16:19:02 coolsvap: I forgot about the kerenl version 16:19:20 Ok... so there's a lot of work there 16:19:27 jgriffith: I think I have that setup as well 16:19:33 the decision on what's default and what's not may not be cut and dry 16:19:44 jgriffith: let me double check 16:19:47 but I think starting with cleaning up LIO and beefing it up seems good 16:19:53 and doesn't hurt anyone 16:20:01 jgriffith: yes, I've started on this 16:20:05 We'll def make sure we don't cut out a platform 16:20:10 at least the emails to fix up the packages 16:20:28 righty ho 16:20:28 I like the idea of a fallback to tgt tho 16:20:40 thingee: yeah, seems like a reasonable approach 16:21:39 jgriffith: I have seen some issues with LIO preconfigured with RDO-icehouse, I just dont remember whether I got those on 7/6 16:21:52 I will check that tonight 16:22:12 coolsvap: k... but it seems we know that el6 isn't going to work 16:22:22 * jgriffith trusts eharney on all things rhel :) 16:22:26 :-( 16:22:35 there was at least one big bug around LIO fixed in icehouse rc phase too 16:22:44 Not a problem though 16:23:06 * coolsvap wants to join the club with eharney 16:23:10 eharney: heh missing module import 16:23:12 * coolsvap ;) 16:23:46 thingee: oh i forgot about that one... i meant the elevated context thing 16:23:58 jgriffith: that's all for me. I will hopefully have a better report. I *just* started on the clean up stuff last night 16:24:09 better report at the summit* 16:25:44 jgriffith: Will discussing issues around Volume states be discussed in the Cinder State and Workflow Mangement discussion? 16:26:35 * jgriffith gets in his time machine..... 16:26:56 jungleboyj: I just visited the session in the future and it seemed like you brought it up 16:27:22 * jungleboyj laughs ... Ok. 16:27:32 alright... anybody else have anything? 16:27:46 https://blueprints.launchpad.net/cinder/+spec/cinder-volume-metadata-for-backup-restore 16:27:47 jgriffith: Then you can kick me out as I will have to leave for a flight soon after that. 16:28:08 Can anybody give me the slightest clue what that is about? 16:28:56 reads kind of like the import/export ideas to me 16:28:58 but i dunno 16:29:16 eharney: DuncanT I *think* it's just a mapping 16:29:24 which I'm not overly interested in creating a table for 16:29:32 the driver should be able to handle this 16:29:40 no idea what he's talking about....some new metadata object ? 16:29:42 why? 16:29:43 and we already have a "host" column on the volume 16:30:10 sounds like he wants to store the state of cinder's db on the storage array? 16:30:13 no idea 16:30:25 hemna: DuncanT eharney so I believe what he wants here is: 16:30:35 ability to querie cinder to do direct backup of volumes 16:30:39 outside of Cinder 16:30:54 so for example tell netbackup: Here's the device, this is the volume back it up 16:31:07 it's come up in some talks I've been in before 16:31:26 traditional backups, NOT cinder backup service BTW 16:31:36 then why do we need to modify cinder to support something that happens outside of cinder ? 16:31:52 hemna: so they can have the mapping 16:32:08 hemna: they need to tell the back up app how to find the volume on the device 16:32:14 just map based on identifying the volumes from the array side by a name that corresponds to the cinder id? 16:32:17 jgriffith: Why does that have anything to do with nova device mapping info? 16:32:26 eharney: yeah, if your driver implemented that :) 16:32:34 DuncanT: that I'm not sure 16:32:37 DuncanT, no idea 16:32:56 jgriffith: Fair enough, I guess we'll find out at the summit 16:33:00 I'm assuming they want to backup the instance data as well? 16:33:35 * jgriffith isn't a fan regardless but we'll see 16:34:22 anything we can't discuss iformally in #openstack-cinder? 16:34:22 But the instance and attachment data can change mid-backup.... 16:34:29 the 3PAR drivers already do some of this when we create a volume. 16:34:41 we store some cinder metadata in the volume on the 3PAR itself 16:34:55 alright... let's wrap it up 16:35:00 for reverse lookup (when looking at the 3PAR UI console) 16:35:15 hemna: most of us implemented that from the start yes 16:35:31 so I guess this BP is just a formalization of that concept ? 16:35:48 not sure why the drivers need a new API for it? 16:36:00 hemna: well everybody does it differently 16:36:10 yah I suppose it enforces it then 16:36:13 hemna: so having an API call to just give the mapping is what they want and makes sense 16:36:31 but again I didn't write the BP so there's a lot of speculation going on here 16:36:40 that may prove to be a waste of time :) 16:36:47 heh yah 16:37:09 We'll need to clairfy things with yehia 16:37:22 alright... anything for the meeting before i turn out the lights? 16:37:40 * jgriffith isn't trying to rush, just be focused 16:37:44 no meeting next week? just kidding 16:37:48 kmartin: LOL 16:38:06 *thinks there will be MANY meetings next week* 16:38:08 kmartin: on the contrary 16:38:13 LOTS of meeting next week 16:38:19 I would like to finalize at the summit a time for us all to meet in the second milestone 16:38:20 glenng: +1 16:38:35 finalize = start discussion 16:38:43 thingee: I was wondering if that was going to come up 16:38:47 thingee: noted 16:38:57 thingee: and another bug hunt day 16:39:02 thingee: we'll propose a mid-cycle sprint and try to get somethign worked out 16:39:14 kmartin: yes, google hangout 3rd milestone 16:39:17 great success 16:39:24 kmartin: thingee we can do those things over IRC too though IMO 16:39:25 yah 16:39:27 don't need to be in person 16:39:40 I mean... propose/schedule 16:40:15 Summit/Session time is valuable, we need to use it for things we can not do virtually 16:40:31 sure 16:41:43 I'd propose an informal get together after the last session on Friday 16:41:57 quick summary and plans for things like mid cycle sprint, bug days etc 16:42:16 jgriffith, +1 16:42:31 jgriffith: sounds good...I'll be there till Saturday 16:42:33 or even an unconference on Monday could cover that as well 16:43:07 hemna: I think it's hard to have a summary before we have our sessions 16:43:10 :) 16:43:21 and I"m not letting everybody borrow my time machine 16:44:30 alright... end meeting? 16:44:33 going once.... 16:44:37 * DuncanT probably shouldn't be allowed to drive other poeple's time machines... he keeps denting his own 16:44:46 :) 16:44:52 going twice.... 16:45:02 we out 16:45:14 out we go! 16:45:15 remember we have openstack-cinder and -dev channels 16:45:19 #endmeeting