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