16:00:28 <jgriffith> #startmeeting cinder
16:00:29 <openstack> Meeting started Wed Aug 14 16:00:28 2013 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:33 <openstack> The meeting name has been set to 'cinder'
16:00:35 <jgriffith> Hey everyone
16:00:44 * bswartz waves hello
16:00:54 <DuncanT-> Hey
16:00:55 <eharney> hi
16:00:56 <xyang_> hi
16:00:59 <jgriffith> #link https://wiki.openstack.org/wiki/CinderMeetings
16:01:01 <garyk> hi
16:01:06 <jgriffith> hey garyk
16:01:10 <kartikaditya> hi
16:01:10 <kmartin> hello
16:01:14 <jgriffith> avishay?????
16:01:16 <jungleboyj> Hello all.
16:01:18 <jgriffith> no avishay
16:01:21 <garyk> jgriffith: thanks for looking at the code
16:01:29 <jgriffith> garyk: no worries
16:01:31 <thingee> o/
16:01:34 <jgriffith> thingee: :)
16:01:37 <tjones> hi
16:01:40 <zhiyan> hi
16:01:42 <jgriffith> You get to go first
16:01:53 <jgriffith> #topic API extensions using metadata
16:01:57 <thingee> excellent
16:02:03 <zhiyan> good
16:02:10 <thingee> so some meeting ago we spoke about storing extension data in metadata
16:02:35 <thingee> since extensions on optional features, having changes to model and risking columns being unused seemed to not make sense
16:02:39 <bswartz> is this the metadata that's supposed to be for end users to tag their volumes?
16:02:54 <bswartz> end user = tenant
16:02:57 <zhiyan> key/value pair for the volume.
16:03:00 <thingee> bswartz: wrt https://review.openstack.org/#/c/38322/
16:03:18 <zhiyan> actually, i'm agree to using 'metadata' for extension. but in this R/O volume case, i just think 'readonly' property of volume should not put into metadata but volume table/model. since for next multiple-attaching feature change, i'd like keep 'readonly' as a property for the volume, LIKE others such as 'instance_uuid', 'attach_time' and etc., those attaching related properties will all be removed to a dedicated table.
16:03:40 <thingee> storing if a volume is readonly. Not all cases will we have backend solutions that support this. IMO, this is optional, and so I feel like the model shouldn't be changed
16:03:54 <thingee> otherwise you end up with columns being unused and worse of all the volume table growing :(
16:03:59 <winston-1> thingee: +1
16:04:22 <jgriffith> thingee: I agree with your statements, but I'm on the fence with this particular change
16:04:28 <thingee> we already have other patches aiming towards this direction and we should continue this path with new stuff coming in
16:04:43 <jgriffith> thingee: +1
16:04:56 <vincent_hou> zhiyan: there is a volume-acl being implementing about the readonly property
16:05:05 <DuncanT-> Can we differentiate between what the API calls metadata and this please?
16:05:05 <thingee> And I don't think it's zhiyan fault at all. It was discussed in a meeting, but there is no documentation about this. I think that needs to be improved and something I'm willing to take on to help people writing extensions.
16:05:32 <jgriffith> DuncanT-: back to the discussions about QoS
16:05:34 <DuncanT-> I've no problem storing it in some k/v table, but volume metadata is already a thing, and I don't think changing that is a good idea
16:05:44 <bswartz> DuncanT-: +1
16:05:44 <jgriffith> DuncanT-: not putting dedicated columns in the DB/Volume obj
16:05:59 <thingee> DuncanT-, jgriffith: so I think we talked about admin metadata at one point? Just can't be changed by a user
16:06:01 <jgriffith> but using abstracted K/V's or AKA meta
16:06:01 <zhiyan> if you really like keep request 'readonly' save to 'metadata',  i would rather remove that extension in this r/o attaching case, as avishay said, using 'update' standard api, but extension for 'readonly' flag update.
16:06:08 <thingee> I think that would make the distinction
16:06:08 <jgriffith> thingee: indeed
16:06:31 <jgriffith> thingee: did my simple explanation attempt line up with your thoughts as well?
16:06:34 <DuncanT-> jgriffith: I've no problem with the concept, I'd like to kill the name 'metadata' ASAP to avoid confusion
16:06:37 <avishay> hi, sorry i'm late
16:06:44 <jgriffith> DuncanT-: I'm fine with that
16:06:52 <thingee> DuncanT-: definitely
16:07:35 <thingee> zhiyan: so if we ended up with using some idea of metadata, I'm with the extension having it's on change readonly flag. I think other people would agree that wouldn't belong in the volume api update
16:08:07 <thingee> it wouldn't belong in the core api especially if it's optional
16:08:27 <jgriffith> thingee: so that's a good distinction point IMO
16:08:46 <jgriffith> err... "point of distinction"
16:09:14 <thingee> jgriffith: if it was part the volume table, I'd say leave it in core api. but in order for it to have it's only column(s) it would have to be mandatory feature.
16:09:29 <jgriffith> thingee: yeah, I see your point
16:09:41 <jgriffith> thingee: when I went through the patch I looked at it differently though
16:09:54 <jgriffith> thingee: but I think what you're proposing makes perfect sense
16:10:11 <jgriffith> ie I *did* look at it as a core feature
16:10:16 <zhiyan> thingee: but as i mentioned above, for this case i don't think 'readonly' should be separated from volume/model, since it's a status for volume, multiple-attaching will separate them all out to a dedicated table, this will keep consistent IMO, i don't think 'readonly' save to 'metadata', and other's such as 'instance_uuid' be saved to other table is a good idea.
16:10:21 <thingee> ok great. zhiyan I think you had one other last concern with the readonly column remaining in the volume table?
16:10:24 <thingee> ah there it is :)
16:10:29 <avishay> i thought it was a core feature as well...why is it optional?
16:11:09 <thingee> avishay: if it's not optional, it should be in the core. not in contrib.
16:11:27 <jgriffith> thingee: well, maybe we need to figure out how to define that better
16:11:30 <thingee> I've always wondered why in general volume actions is in contrib
16:11:35 <thingee> admin actions rather.
16:11:52 <jgriffith> thingee: core features can be policy based extensions I believe
16:12:04 <vincent_hou> https://review.openstack.org/#/c/39683/ the readonly can be defined by the permission.
16:12:06 <avishay> thingee: i thought it should be in api/v2/volumes.py  : update()
16:12:11 <zhiyan> thingee: ok, if so, i will remove that extension api, then to ask client use standard update api to change 'readonly' flag.
16:12:37 <jgriffith> vincent_hou: I really don't like that direction at all
16:12:38 <vincent_hou> by checking the permission level, you can it is readonly or not.
16:12:40 <jgriffith> personally
16:12:42 <zhiyan> folks, do you think is acceptable?
16:12:59 <zhiyan> it is acceptable?
16:13:06 <thingee> well ok step back a second. is this a core feature or not? Is every backend solution really going to be able to provide this feature?
16:13:18 <DuncanT-> Every hypervisor can
16:13:21 <DuncanT-> AFAICT
16:13:22 <zhiyan> yes
16:13:23 <jgriffith> thingee: so that's the million dollar question
16:13:36 <DuncanT-> Backend enforcement is a grey area
16:13:38 <jgriffith> thingee: my thought was yes, because the hypervisor can implement it
16:13:40 <jgriffith> BUT
16:13:45 <hemna> mornin
16:13:46 <avishay> i thought it was optional for drivers, but all hypervisors would support
16:13:57 <jgriffith> thingee: I'm also good with the idea of graduating later
16:14:04 <zhiyan> if all cinder backend can support it , it will be better, but as DuncanT mentioned, hypervisor can support it.
16:14:14 <thingee> jgriffith: My fear with that is migrating to the volume table then.
16:14:15 <zhiyan> jgriffith: yes
16:14:15 <avishay> zhiyan: all backends CAN'T support it
16:14:29 <thingee> jgriffith: I feel like if we see ourselves graduating it later, we just let it be a core feature.
16:14:29 <avishay> all hypervisors apparently can
16:14:34 <zhiyan> avishay: i mean hypervisor, nova side, but cinder
16:14:35 <jgriffith> thingee: hmmm
16:14:52 <jgriffith> avishay: thingee zhiyan but the problem is that it's not implemented yet
16:15:02 <jgriffith> ie on the nova/hypervisor side
16:15:03 <zhiyan> jgriffith: yes, i will do that
16:15:09 <avishay> what's the chance of the nova code making havana, at least for libvirt?
16:15:12 <zhiyan> jgriffith: after this cinder server side done
16:15:14 <jgriffith> and we're too late in the cycle to get those changes in I believe
16:15:21 <thingee> jgriffith: so if it's not in nova, we shouldn't merge.
16:15:23 <jgriffith> zhiyan: I don't think that will be possible
16:15:27 <thingee> jgriffith: we can be ready to merge.
16:15:36 <zhiyan> jgriffith: so we need speed up to reveiw/landing, IMHO
16:15:46 <avishay> we can merge now and if the nova code doesn't make it we can revert?
16:16:03 <jgriffith> zhiyan: sure, but if there's not a bp for nova work already you're likely going to be too late
16:16:13 <jgriffith> avishay: I'd rather not
16:16:15 <zhiyan> https://review.openstack.org/#/c/34722/2
16:16:27 <jgriffith> avishay: we can agree on exceptions for Cinder if need be, but not revert
16:16:34 <thingee> avishay: I'd be fine with that if we weren't low on resources as it is for reviews that are likely to make it
16:16:35 <avishay> jgriffith: ok
16:16:40 <winston-1> if it's hypervisor, it's a state of the 'connection' to the volume instead of the state of volume itself.  do we want to be able to distingish these two?
16:16:43 <jgriffith> avishay: remember there are folks running trunk and that can make a mess for them
16:16:51 <thingee> jgriffith: +1
16:16:56 <jgriffith> winston-1: +1
16:17:04 <jgriffith> winston-1: that brings up a good point
16:17:12 <DuncanT-> Nova are refusing to merge until the cinder part is merged. If we refuse until nova merge we've a problem....
16:17:12 <jgriffith> winston-1: I did something similar with the blocksize
16:17:22 <jgriffith> DuncanT-: ha!
16:17:24 <thingee> DuncanT-: heh
16:17:36 <jgriffith> so let's not get off track here
16:17:39 <thingee> you merge first, no you merge first!
16:17:41 <jgriffith> let's back up
16:17:52 <jgriffith> first we need to decide what we *want*
16:18:00 <zhiyan> winston-1: we discussed this very former, 'readonly' is a status for volume, and also 'attached_mode' is for attach seesion of a volume.
16:18:28 <jgriffith> zhiyan: but... attach info is used for attach which is when r/o would be needed/checked
16:18:37 <hemna> which it currently isn't
16:18:58 <jgriffith> The only thing I don't like about using K/V's or connect info
16:19:09 <jgriffith> we need some way to communicate to the tennant it's R/O
16:19:17 <jgriffith> otherwise silly things happen
16:19:57 <jgriffith> admin-meta may be fine, but then we're saying that's all end-user visible (not modifyable)
16:20:04 <zhiyan> jgriffith: what's 'tennant' ? sorry
16:20:08 <jgriffith> haha... it's Read Only
16:20:15 <jgriffith> zhiyan: end-user of openstack
16:20:24 <jgriffith> Our customers :)
16:20:27 <zhiyan> jgriffith: readonly
16:20:43 * jgriffith thought it was funny
16:20:51 <jgriffith> and so did his dog
16:20:57 <zhiyan> jgriffith: IMO, query 'readonly' status of the volume from db/model IMO..
16:21:08 <jgriffith> zhiyan: yes, understood
16:21:19 <jgriffith> zhiyan: I think we're all clear on that :)
16:21:23 <jgriffith> I'd like input from others
16:21:41 <jgriffith> Specifically about it being a core function or not
16:21:53 <jgriffith> or not core now, core later etc
16:22:07 <jgriffith> Unfortunately it's getting late in the cycle
16:22:26 <jgriffith> Nobody has an opinion there?
16:22:27 <bswartz> as long as some backends can't support it we need to explain how those should treat R/O requests
16:22:33 <avishay> I think if KVM supports it, and others can, it should be core.  It all depends on what can realistically get into Havana.
16:22:36 <thingee> jgriffith: if it's not going to make it into nova where they're in a ready state to merge, then we shouldn't merge.
16:22:37 <jgriffith> bswartz: hypervisor
16:22:40 <DuncanT-> I think if we're going to support multi-attach, we need this as core at some point
16:22:48 <hemna> at this point I think H is too late
16:22:48 <jgriffith> thingee: I agree with that
16:22:49 <zhiyan> how about just put it in extension, but save 'readonly' to volume table but not metadata ?
16:22:52 <hemna> and we should plan for I
16:23:06 <jgriffith> zhiyan: isn't that what you already said?
16:23:19 <thingee> hemna: +1
16:23:23 <jgriffith> hemna: you give up too easy
16:23:25 <bswartz> the hypervisor approach doesn't address volumes which are read-only on the backend and can't be made writable
16:23:28 <thingee> :)
16:23:30 <hemna> :P
16:23:32 <avishay> what's the benefit of having driver support for this if all hypervisors support it?  two levels of read-only?
16:23:33 <zhiyan> jgriffith: i can remove that from extension, and ask use using standard update api.
16:23:34 <jgriffith> bswartz: ?
16:23:42 <jgriffith> bswartz: that's fairly easy to address actually
16:24:00 <DuncanT-> avishay: Belt and braces / defense in depth?
16:24:01 <bswartz> well the obvious solution is: don't do that, but I'm curious about a better solution
16:24:04 <jgriffith> bswartz: indicate via the K/V structure "backend supported"
16:24:14 <bswartz> okay
16:24:20 <jgriffith> then if not backend: hypervisor
16:24:29 <avishay> DuncanT-: OK
16:24:44 <bswartz> there's a 3rd state though: backend can report r/o but backend cannot change r/o
16:24:51 <jgriffith> Ok, it seems there's only two opinions being voiced here
16:24:53 <avishay> DuncanT-: that's what i thought...might be a little overkill for my taste, but OK
16:24:53 <DuncanT-> I'd suggest that if a backend can't make things writeable, it should make them R/O, but then it's a pretty weird backend even by my standards in that case
16:24:57 <jgriffith> 1. Wait until I
16:25:06 <jgriffith> 2. Move forward with the proposed patch
16:25:12 <avishay> DuncanT-: 'even by my standards' :)
16:25:15 <jgriffith> I was hoping for an option 3
16:25:30 <thingee> jgriffith: option 3 is store in metadata
16:25:44 <jgriffith> yay!
16:25:48 <thingee> and still get in for I
16:25:53 <jgriffith> but you said the M word!!
16:25:56 <DuncanT-> Given we need to hit the hypervisors to get this to actually work, we can't call it core until most if not all the hypervisor work is done
16:26:06 <jgriffith> I'm not so ready to give up on H yet
16:26:11 <jgriffith> but I'll have to take that offline
16:26:11 <thingee> I'll buy DuncanT- a shot everytime I say metadata.
16:26:18 <thingee> metadata metadata metadata
16:26:22 <jgriffith> and we need to figure out our approach before I can do anything there
16:26:24 <avishay> haha
16:26:27 <DuncanT-> This is going to hurt....
16:26:35 <hemna> I presume this would also affect brick's attach/detach support for both iSCSI and FC
16:26:46 <jgriffith> hemna: yep
16:27:08 <caitlin-nexenta> Sorry for jumping in late, but I'd like to ask a very basic question. What is the need to create a "read-only volume" when we have already defined snapshots?
16:27:17 <DuncanT-> Hmmm, given the amount of dependencies and complications arising, punt until I is growing on me
16:27:22 <jgriffith> snapshots don't have much to do with it
16:27:27 <hemna> DuncanT-, +1
16:27:31 <DuncanT-> caitlin-nexenta: You attach a snapshot
16:27:33 <jgriffith> caitlin-nexenta: the end goal is multi-attach
16:27:37 <DuncanT-> Gah
16:27:45 <jgriffith> caitlin-nexenta: starting with R/O volumes to do so
16:27:46 <DuncanT-> *Can't* attacha snapshot
16:27:51 <avishay> caitlin-nexenta: you can't attach snapshots
16:28:09 <thingee> ok we're losing focus
16:28:14 <caitlin-nexenta> But you can clone snapshots.
16:28:24 <DuncanT-> Then they aren't read only
16:28:26 <jgriffith> caitlin-nexenta: but then it's a volume and round and round we go :)
16:28:39 <avishay> OK, decision time?
16:28:50 <zhiyan> avishay: +1
16:29:08 <jgriffith> Who wants to leave it in teh volume table?
16:29:12 <DuncanT-> I vote to punt until summit discussion / I
16:29:14 <jgriffith> besides zhiyan :)
16:29:23 <jgriffith> DuncanT-: Not on the list
16:29:27 <thingee> heh
16:29:42 <zhiyan> think about next mutli-attach change
16:29:48 <zhiyan> keep consistent
16:29:58 <DuncanT-> "1. Wait until I"
16:30:01 <avishay> what's the chance of the libvirt support landing in H?
16:30:05 <hemna> :P
16:30:15 <thingee> DuncanT-: heh
16:30:19 <hemna> avishay, 0 if the cinder patch doesn't land first
16:30:21 <jgriffith> zhiyan: I understand that point, however I'm kind of in the opinion that if that changes something drastically we address it then
16:30:32 <hemna> we'll also need a patch to change brick to support this
16:30:33 <zhiyan> not sure, i need time, but block on review you know
16:30:40 <jgriffith> ok, you guys are killing me
16:30:44 <avishay> hemna: let me rephrase...given that the cinder patch lands tomorrow, what's the chance of libvirt support in H?
16:30:47 <jgriffith> I declare this topic dead
16:31:00 <jgriffith> avishay: I think it could get in
16:31:04 <hemna> avishay, hard to tell, there are over 300 outstanding reviews in nova today
16:31:09 <avishay> so i say give it a chance
16:31:16 <DuncanT-> If we merge an API into to cinder that flat out doesn't work, that's bad IMO
16:31:18 <jgriffith> avishay: that's the spirit
16:31:37 <jgriffith> Ok, moving along
16:31:38 <DuncanT-> And that is the case if we merge before nova merge
16:31:41 <jgriffith> zhiyan: we can chat later
16:31:46 <thingee> jgriffith: if we do see it a core feature, can we rethinking the columns. Just looking at the model changes now seemed not straight forward from outside perspective and overlap.
16:31:47 <jgriffith> we'll figure something out
16:31:52 <jgriffith> thingee: you too
16:32:05 <jgriffith> thingee: I'm all for rethinking the columns
16:32:12 <jgriffith> in fact I'm agreeing with you on that one
16:32:28 <jgriffith> but everybody is busy arguing amongst themeselves about Nova and I etc
16:32:36 <thingee> ok next topic
16:32:42 <jgriffith> #topic migration
16:32:48 <jgriffith> avishay: what's up?
16:33:17 <jgriffith> avishay: ???
16:33:18 <avishay> so i have patches up for cinder being able to migrate in-use volumes, and also patches for cinderclient and nova to go along with it
16:33:47 * jgriffith is abstaining from the cinder patch at this point
16:33:51 <avishay> the detached case code that was merged required drivers to implement rename_volume for migration to work, and i got rid of that
16:34:04 <avishay> so now all drivers that have support in brick have migration for free
16:34:21 <avishay> there are 2 dependencies though
16:34:35 <DuncanT-> What about the none-brick ones?
16:34:54 <hemna> avishay, nice
16:35:06 <avishay> DuncanT-: online migration via libvirt will work, but cinder can't copy data for detached if brick doesn't support
16:35:13 <avishay> DuncanT-: they can override the copy function though
16:35:18 <DuncanT-> avishay: Cheers
16:35:22 <jgriffith> avishay: maybe you should clarify by "brick"
16:35:30 <avishay> brick attach/detach code
16:35:39 <avishay> so iSCSI and FC is there, NFS and others is not
16:35:42 <jgriffith> avishay: aka iscsi/fc
16:35:44 <jgriffith> :)
16:35:49 <caitlin-nexenta> avishay - can a storage vendor optimize migration for their devices?
16:35:49 <jgriffith> thanks
16:36:05 <avishay> caitlin-nexenta: yes - see here https://review.openstack.org/#/c/41046/
16:36:12 <avishay> so i have 2 dependencies
16:36:21 <hemna> so we need connectors for nfs, iser, aoe, etc then
16:36:23 <avishay> 1. eharney and i are working out how to interface with novaclient
16:36:29 <avishay> hemna: aoe is submmitted
16:36:36 <bswartz> hemna: I'm doing a nfs one
16:36:42 <jgriffith> iser is in too IIRC
16:36:43 <hemna> ok excellent
16:36:48 <avishay> 2. i need help from thingee on this https://review.openstack.org/#/c/40857/
16:37:02 <hemna> if you guys need help on the connectors...I'm here.
16:37:02 <avishay> but the code is ready for whoever is interested to test, and for everyone to review
16:37:30 <winston-1> anyone works on RBD for brick?
16:37:42 <winston-1> dosaboy: ?
16:37:42 <winston-1> jdurgin: ?
16:37:44 <jgriffith> winston-1: that model doesn't really *fit*
16:37:58 <dosaboy> winston-1: how imment is it needed?
16:38:03 <jgriffith> winston-1: but maybe dosaboy ?
16:38:04 <dosaboy> I am happy to work on it
16:38:05 <jgriffith> ha
16:38:17 <dosaboy> got a fair bit on already
16:38:18 <jgriffith> dosaboy: this week :)
16:38:22 <dosaboy> eeeek
16:38:22 <avishay> RBD can override the driver's copy_volume_data (or whatever it's called) function with a simple 'cp' to get detached migration working
16:38:52 <jgriffith> avishay: to clarify again though, you're talking migrate to same back-end right?
16:39:02 <avishay> jgriffith: absolutely not :)
16:39:05 <hemna> avishay, what do you mean by detatched migration?  detached from a VM ?
16:39:05 <dosaboy> avishay: can I ping you tomorrow on this?
16:39:11 <avishay> hemna: yes
16:39:12 <jgriffith> avishay: so LVM --> RBD
16:39:14 <avishay> dosaboy: sure
16:39:16 <hemna> ok
16:39:17 <dosaboy> thx
16:39:34 <jgriffith> avishay: and the reverse as well?
16:39:40 <avishay> jgriffith: LVM vg A to LVM vg B, or LVM to storwize to RBD to whatever
16:39:52 <avishay> jgriffith: two different cinder backends, no matter what the type
16:40:10 <jgriffith> avishay: k, last time we chatted I thought that was NOT the case
16:40:12 <med_> nod.
16:40:16 <avishay> jgriffith: yes it was
16:40:23 <jgriffith> avishay: hmmm
16:40:25 <winston-1> avishay: nice!
16:40:37 <avishay> jgriffith: you asked what the difference between miration and clone was
16:40:44 <jgriffith> avishay: ?
16:40:49 <hemna> eventually it would be nice to see if the backend had hints on migration.  some backends can move volume between themselves to avoid the dd/cp over the network.
16:40:54 <avishay> jgriffith: clone is specifically in the same back-end, migration is moving the volume somewhere else
16:41:04 <jgriffith> avishay: I'm fully aware of what clone is thanks
16:41:11 <avishay> hemna: drivers have the option to do it themselves
16:41:33 <hemna> avishay, ok, are there hints to the driver that let it know what the destination is ?
16:41:33 <avishay> jgriffith: i'm just saying that's what you asked last time
16:41:44 <jgriffith> avishay: no, it's not but that's ok
16:41:53 <avishay> hemna: the driver gets the name of the host and its capabilities
16:41:55 <jgriffith> avishay: doesn't matter so long as I was wrong :)
16:42:15 <avishay> jgriffith: yeesh... you also said you were a smart ass :)
16:42:30 <jgriffith> whoooo... meeeee?
16:42:33 <hemna> say moving from one 3par to another 3par.  my driver can instruct the 3pars to do the work between themselves
16:42:44 * jgriffith thinks somebody is impersonating him
16:42:45 <avishay> hemna: see here: https://review.openstack.org/#/c/41046/
16:42:50 <hemna> avishay, thn
16:42:52 <hemna> thnx
16:42:52 <caitlin-nexenta> avishay - do you have a summary of the assumptions your patch is making. For example, are you assuming that copying the volume data is always a full copy?
16:43:19 <avishay> caitlin-nexenta: yes, moving the entire volume from "here" to "there"
16:43:45 <avishay> the interface is:  cinder migrate <volume-id> <destination host> [--force-host-copy True]
16:44:09 <avishay> The force-host-copy flag can be used to disable a driver's optimized version and use cinder/nova to copy
16:44:25 <avishay> In case of a driver bug, for example, your data isn't stuck
16:44:33 <caitlin-nexenta> Some storage servers have the ability to create what is effectively a remote thin clone, and be very lazy about how complete the migration is. What would we have to do to preserve that capability for our servers?
16:44:55 <avishay> caitlin-nexenta: i think we should take that offline
16:45:03 <caitlin-nexenta> No problem.
16:45:22 <avishay> jgriffith: we good?
16:45:22 <hemna> avishay, I'd like to ping you offline about this as well to better understand my optimized mechanism as well.
16:45:27 <jgriffith> I'm good
16:45:30 <avishay> hemna: no problem
16:45:54 <avishay> hemna: if you review my patch you will understand it ;)
16:46:05 <hemna> I'm reading through it now thanks
16:46:12 <winston-1> avishay: :)
16:46:26 <avishay> but seriously, will be happy to help anyone who needs more understanding, and will work on docs as well
16:46:45 <avishay> oh, one more thing
16:47:00 <avishay> _ seems to be missing, and that's why the patch isn't passing py26 and py27
16:47:14 <avishay> any idea where it went?
16:49:38 <avishay> guess not
16:49:39 <avishay> hello?  anybody home?
16:49:54 <jgriffith> avishay: have you rebased
16:49:54 <jgriffith> avishay: I'll have a look at your patch later and see if I can help out there
16:49:55 <jgriffith> avishay: it's likely related to some pulls from OSLO
16:49:55 <jgriffith> avishay: but the fact that other patches are going through makes me wonder if a rebase would handle it
16:49:58 <jgriffith> anything else?
16:50:04 <ZChao> I have a patch for huawei driver: https://review.openstack.org/#/c/36294/
16:50:07 <avishay> wow i just got all your messages at once...strange
16:50:13 <hemna> lagged
16:50:13 <kartikaditya> jgriffith: https://review.openstack.org/#/c/41600/ posted vmdk driver couple of APIs
16:50:16 <jgriffith> avishay: that happened last night too
16:50:20 <avishay> jgriffith: will try to rebase - thanks
16:52:23 <jgriffith> whoaaaa there folks
16:52:23 <jgriffith> kk
16:52:23 <winston-1> avishay: freenode is lagging very badly
16:52:23 <jgriffith> avishay: nothing else?
16:52:24 <ZChao> hope anyone instrested in this could find time to review
16:52:24 <jgriffith> #topic other stuff
16:52:24 <jgriffith> Ok, now the free-for all
16:52:24 <jgriffith> but PLEASE
16:52:24 * med_ lost his connection
16:52:24 <jgriffith> don't ask "review my patch"
16:52:24 <jgriffith> we're all painfully aware of what's in the queue
16:52:24 <jgriffith> NO offense... just sayin
16:52:24 <garyk> jgriffith: :)
16:52:24 <ZChao> ok,i understand
16:52:24 <jgriffith> alright... if nobody has anything else?
16:52:28 <jgriffith> remember proposal freeze next week (21'st)
16:52:30 <caitlin-nexenta> Is there a good document anywhere that summarizes the philosophy of what a snaphshot, backup, etc. should be used for?
16:52:45 <jgriffith> caitlin-nexenta: there are some comments on Victors patch if you guys can get to it
16:52:48 <avishay> my connection sucks, i'm dropping off
16:52:49 <avishay> bye all
16:52:58 <jgriffith> I can explain the multi-backend stuff if needed
16:53:08 <jgriffith> caitlin-nexenta: other than it's pretty much good to go
16:53:21 <jgriffith> alright...
16:53:22 <dosaboy> caitlin-nexenta: i have a task open to update the docs on backups
16:53:27 <jgriffith> thanks everyone
16:53:35 <jgriffith> #end meeting
16:53:38 <jungleboyj> Later.
16:54:06 <bswartz> jgriffith: #endmeeting is one word
16:54:12 <jgriffith> #endmeeting