16:01:55 <jgriffith> #startmeeting cinder
16:01:56 <openstack> Meeting started Wed Oct 23 16:01:55 2013 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:00 <openstack> The meeting name has been set to 'cinder'
16:02:03 <jgriffith> Hey everyone
16:02:03 <thingee> o/
16:02:06 <avishay> hello
16:02:09 <jjacob512> hello
16:02:10 <xyang1> hi
16:02:14 <DuncanT> hey
16:02:16 <eharney> hey
16:02:20 <aguzikova> o/
16:02:27 <jgriffith> DuncanT: take it away...
16:02:33 <jgriffith> #topic nexenta backup driver
16:02:41 <DuncanT> https://review.openstack.org/#/c/47005/
16:02:49 <jgriffith> DuncanT: and I have already discussed BTW :)
16:02:58 <med_> \o
16:03:07 <DuncanT> Short version: I think it's a terrible idea, a bad trend, and even if it wasn't then I think it's a bad implementation
16:03:24 <caitlin56> Which patch specifically?
16:03:25 <bswartz> hi
16:03:40 <DuncanT> I'm happy to be convinsed otherwise however and I'm not going to get upset if people tell me I'm wrong
16:03:40 <avishay> don't be too subtle about how you feel :)
16:03:54 <dosaboy> :)
16:04:02 <DuncanT> caitlin56: https://review.openstack.org/#/c/47005/
16:04:24 <caitlin56> Ok, this one should be short. I agree.
16:04:30 <DuncanT> Nice :-)
16:04:37 <jgriffith> Well that was easy
16:04:46 <caitlin56> The objectives are good, but we need to repackage them in a way that deals wsith Duncan's points.
16:05:06 <jgriffith> caitlin56: ummm... wait
16:05:11 <jgriffith> caitlin56: might be missing the point, not sure
16:05:21 <dosaboy> and (while we're at it) could you make sure metadata backup is factored in
16:05:35 <jgriffith> caitlin56: which *objectives* exactly are good in your opinion?
16:06:08 <caitlin56> Using other servers to make replicas of your content in cost effective ways. Notice that I'm avoiding using the term "backup".
16:07:02 <avishay> caitlin56: what is the scenario?  tiering?
16:07:10 <rushiagr2> hi all!
16:07:15 <rushiagr2> sry, late
16:07:23 <jgriffith> rushiagr: howdy
16:07:24 <avishay> caitlin56: i.e., copy the volume over and then delete it, and restore if you want to use again?
16:07:46 <DuncanT> That's fair. I think we need to get a clear aim around backup and keep it focused...
16:08:04 <caitlin56> Disaster recovery, warm standby, pre-migration.
16:08:04 <caitlin56> I can replicate content between two like servers more effectively than I can create a vendor neutral "Backup".
16:08:08 <guitarzan> I think it's sensible to have more than just the swift backup driver
16:08:19 <DuncanT> Backend migration / cross-backend cloning is a better for this than backup I think
16:08:43 <avishay> and here i am coding up a prototype of volume mirroring...
16:08:44 <DuncanT> guitarzan: There#s already ceph and TSM...
16:08:48 <caitlin56> avishay: or just copy it to other targets in case the first target fails.
16:08:53 <guitarzan> DuncanT: I'll take that as a point for me :)
16:09:11 <guitarzan> but this patch does seem to do a lot more than just that
16:09:15 <avishay> caitlin56: HA / DR
16:09:23 <caitlin56> Volume mirroring is "hot standby", correct? Each write is *immediately* transferred?
16:09:36 <avishay> caitlin56: correct
16:09:37 <caitlin56> This is lower cost, replicate periodically.
16:09:42 <avishay> caitlin56: actually, no
16:09:44 <caitlin56> Not continuously.
16:10:03 <avishay> caitlin56: there can be sync, async, snapshots at intervals, etc.
16:10:06 <jgriffith> Ok... so questions
16:10:18 <jgriffith> caitlin56: Are you talking backup or replication?
16:10:27 <jgriffith> caitlin56: replication is not backup
16:10:49 <avishay> backup can be thought of as replication with high RPO :)
16:10:49 <caitlin56> Replication can be a method of providing extra copies of a volume.
16:10:55 <jgriffith> avishay: ewww
16:11:02 <caitlin56> That is also the purpose of a "backup".
16:11:09 <jgriffith> alright, I'm out
16:11:14 <avishay> lol
16:11:22 <caitlin56> Backup can also be vendor neutral, but at a cost that may be too high.
16:11:29 <avishay> i didn't say i like it, but it's true
16:11:35 <avishay> and people use it
16:11:37 <caitlin56> vendor neutral backup is bettr, but it is also more expensive.
16:11:42 <jgriffith> avishay: understood
16:12:24 <DuncanT> The backup API is aimed at offline, cinder-can-catch-fire-and-your-data-is-safe style backups, and I'd like to try to keep that focus
16:12:29 <caitlin56> We have NexentaStor customers who use ZFS send incremental replication to "backup" ZVols.
16:12:49 <jgriffith> caitlin56: so what's your point?
16:12:57 <caitlin56> We want to be able to let them do the same thing under Cinder. The first draft didn't do it right.
16:12:59 <jgriffith> caitlin56: that's fine, lots of vendors do replication
16:13:13 <thingee> I keep seeing "hot" and "warm". Lets be clear that backups are cold.
16:13:19 <jgriffith> thingee: +1
16:13:25 <winston-d> thingee: +1
16:13:31 <thingee> if you're not doing that, you're not implementing something for the backup service.
16:13:33 <jgriffith> I really prefer to keep the contexts separate
16:13:36 <DuncanT> thingee: +1
16:13:42 <caitlin56> thingee: agreed, so calling this a "Backup" was a mistake.
16:13:47 <bswartz> I think there are more gray areas than people are admitting to
16:13:53 <avishay> so what i will propose at the summit will allow back-ends (and front-ends) to implement replication however they want
16:14:05 <bswartz> hot backups do exist -- for different reasons than cold backups do
16:14:09 <jgriffith> bswartz: there are but we have a chance to make some definitions in Cidner and I think we should
16:14:19 <DuncanT> I think havign a replication interface and API is great, I just don't want it merging into backups
16:14:26 <jgriffith> DuncanT: +1
16:14:28 <avishay> DuncanT: agreed
16:14:29 <DuncanT> jgriffith: +1 million
16:14:30 <jgriffith> That's my point
16:15:03 <jgriffith> TBH I'm still a little leary on replication API's / interfaces in some sense
16:15:05 <bswartz> Yes I like the idea of drawing the lines in the sand -- just don't prentend that the reality is black and white
16:15:05 <winston-d> so it's just a naming problem?
16:15:10 <caitlin56> But I agree that we should use different terminology,and keep Ciner "Backups" vendor neutral.
16:15:12 <avishay> i think the difference could be: if you write a bit and do nothing, and it gets copied eventually, it's replication.  if you have to click the 'backup' button, it's backup.
16:15:22 <jgriffith> most vendors are going to have their own replication options that are much better than anythign we're goign to do at a generic level
16:15:30 <med_> +1 jgriffith
16:15:41 <jgriffith> avishay: not a bad summary IMO
16:15:56 <caitlin56> avishay: but what if you have the script push the backup button for you? It's more of a continuum.
16:16:40 <avishay> caitlin56: i know, that's what i said before, but i agree with jgriffith - we should try to define a difference
16:17:04 <caitlin56> I think the bigger difference is whether you are in vendor specific format.
16:17:09 <DuncanT> caitlin56: Come up with a specific usecase and we can discuss it... vague hypotheticals aren't going to help I don't think
16:17:21 <caitlin56> Backups should be vendor neutral. Replication can be vendor optimized.
16:17:48 <caitlin56> DuncantT: I'm working on that presentation for Hong Kong.
16:17:57 <avishay> maybe ideally
16:18:10 <winston-d> DuncanT: I haven't looked at backup code for quite a while, so is it possible to back one volume from back-end A up to back-end B now?
16:18:20 <jgriffith> winston-d: nope
16:18:23 <DuncanT> 'vendor neutral' isn't a useful term here I don't think
16:18:33 <DuncanT> winston-d: Nope, and it isn't meant for that
16:18:36 <jgriffith> winston-d: we shelved that for avishay 's migration work
16:18:40 <jgriffith> or that was my plan anyway
16:18:51 <DuncanT> (what John said)
16:19:18 <caitlin56> But that is the intent, correct? Otherwise why object to vendor specific "backup"?
16:19:25 <DuncanT> Backup is aimed at cold, logically remote storage, and I'd like to keep that focus
16:19:41 <winston-d> DuncanT: oh, right, that was a wrong question. i meant to ask if backup service can live standalone (not staying on the same host of vol service).
16:19:50 <DuncanT> Ceph could be thought of as a vendor, TSM certainly is
16:20:15 <DuncanT> winston-d: I'm not sure that works for all drivers yet, but it is the aim and if you find cases that don't work, please file a bug
16:20:15 <dosaboy> winston-d: to be clear (as mud?) you can backup  a volume created in any backend to any supported backup location
16:20:44 <caitlin56> Duncant: and since it is less frequent there is no reason for it not be in a vendor neutral format.
16:20:56 <jgriffith> dosaboy: +1, I've tested a few and works good thanks to your patch
16:21:04 <DuncanT> caitlin56: It is volume-backend neutral, if that is what you mean
16:21:05 <dosaboy> cool thanks
16:21:23 <caitlin56> DuncantT: yes.
16:21:24 <winston-d> dosaboy: will take a look, thx for clarification
16:21:43 <DuncanT> caitlin56: Ah, yes, very much so, and that totally needs to stay
16:22:19 <avishay> ceph to ceph has special optimizations i think, but it should work for any backend
16:22:21 <caitlin56> DuncanT: Fine, but lets add methods short of full live mirroring where customers can replicate content.
16:22:42 <DuncanT> caitlin56: Yup, I think the replication interface is the place for that, not the backup one
16:22:44 <caitlin56> avishay: vendor optimizations on how stuff is creat3ed is fine.
16:22:59 <avishay> agreed
16:23:03 <caitlin56> agreed.
16:23:17 <jgriffith> I'm still a bit of the opinion that replication is an admin function set up for each back-end external of cinder but whatever
16:23:22 <avishay> all agreed?  we should save some arguments for the summit...will be boring otherwise... :)
16:23:31 <jgriffith> avishay: ha!
16:23:38 <dosaboy> isn't there a new "data protection" project being introduced in HK that aims to take care of replication?
16:23:40 <jgriffith> avishay: haven't you heard, there's new rules for the summit
16:23:44 <dosaboy> the name alludes me
16:23:49 <DuncanT> jgriffith: An in-cinder api for setting replication parameters for a volume isn't a bad aim...
16:23:52 <jgriffith> avishay: no raising of voices, no arguing, peace, harmony and love
16:24:11 <avishay> jgriffith: sounds good to me
16:24:23 <jgriffith> dosaboy: there's a backup service proposals
16:24:23 <winston-d> jgriffith: be 'excellent' ?
16:24:26 <avishay> dosaboy: http://summit.openstack.org/cfp/details/88
16:24:27 <jgriffith> proposal
16:24:32 <caitlin56> dosaboy: any project that doesn'tintegrate with cinder volume backends won't beefficient enough to use.
16:24:36 <med_> jgriffith, I was thinking boxing gloves and waterguns to cool off the hostilities
16:24:48 <DuncanT> I'm going to throw a definition of'cinder backup' on the wiki somewhere while there are some good phrases to steal
16:26:29 <jgriffith> Ok, anything else on this topic (anything productive that is)?
16:26:39 * jungleboyj is here now.  :-)
16:26:48 <jgriffith> jungleboyj: just in time, we're finished :)
16:26:49 <jgriffith> LOL
16:27:18 <jgriffith> alright, DuncanT good for now?
16:27:21 <jungleboyj> jgriffith: Doh!  What did I miss?  These darn short meetings!  ;-)
16:27:27 <DuncanT> jgriffith: Very much so
16:27:46 <jgriffith> caitlin56: anything needed for the meeting?
16:27:47 <DuncanT> jungleboyj: An impressive lack of argument for a change
16:27:50 <winston-d> side track, how many of you will be in HK
16:27:59 * bswartz raises hand
16:28:00 <jgriffith> o/
16:28:01 <avishay> i will
16:28:04 <guitarzan> o/
16:28:10 <DuncanT> I will
16:28:21 <rushiagr> I *most probably* will
16:28:26 <xyang1> I'll be there
16:28:26 <caitlin56> jgriffith: no,just gettingready for Hong Kong sessions.
16:28:34 <eharney> i will
16:28:35 <jungleboyj> DuncanT: :-)  Indeed.
16:28:39 <winston-d> bswartz: you should be right?
16:28:51 <bswartz> yes NetApp is brining a bunch of folks to HK
16:28:54 * med_ lowers his hand in shane
16:28:55 <jgriffith> #topic open discssuion
16:28:59 * med_ lowers his hand in shame
16:29:15 <jgriffith> shane, shame... not sure which is better/worse
16:29:16 <jgriffith> :)
16:29:20 * dosaboy might be, not sure yet
16:29:22 * jungleboyj will be there in spirit.  :-)
16:29:37 <kmartin> not me :(
16:29:42 <avishay> so nobody is brave enough to try volume retype yet?
16:29:42 <bswartz> dosaboy: it's only 1.5 weeks away!
16:29:44 <jgriffith> damn you kmartin
16:29:48 <winston-d> kmartin: really? too bad
16:29:56 <jgriffith> avishay: it's on my list :)
16:30:01 <jgriffith> avishay: I'm hoping this week
16:30:06 <avishay> cool
16:30:10 * jgriffith is a bit preoccupied with other business this week
16:30:12 <winston-d> avishay: haven't reviewed it, not dare to try. :)
16:30:17 <rushiagr> avishay: I'll give it a try too in the comng week
16:30:19 <kmartin> sending me to the AWS re:invent conference instead...yippy
16:30:20 <xyang1> kmartin:  too bad:(
16:30:26 <avishay> awesome
16:30:28 <dosaboy> bswrtz: i know ;)
16:30:36 <avishay> kmartin: sucks, next time!
16:31:01 <kmartin> yep, hemna is going to HK
16:31:06 <jgriffith> alright.. we can jibber jabber in #cinder if there's nothign pressing here?
16:31:08 <jungleboyj> I have a feeling this Iowa boy would have been lost in HK.
16:31:14 <winston-d> hemnafk seems to prepared a big shopping list for HK
16:31:16 <jgriffith> jungleboyj: :)
16:31:34 <hemna> well, sure a guy can always have a list :)
16:31:36 <avishay> jgriffith: any update on the testing suite deal?
16:31:40 <xyang1> kmartin: that's good
16:31:47 <jgriffith> avishay: :)  not really
16:31:54 <jgriffith> avishay: it's on it's way though
16:32:03 <jgriffith> will be submitted before the summit I promise :)
16:32:14 <avishay> jgriffith: HK summit? :)
16:32:23 <jgriffith> avishay: LOL touchet
16:32:26 <rushiagr> avishay: LOL
16:32:37 <med_> heh
16:32:53 <med_> "before the summit"  well played.
16:33:01 <winston-d> ohoh, Advertisement: please take a look at this doc if you are interested in QoS: https://docs.google.com/document/d/1_DEvlzXwOd3bQ4NqXmAS6gIdz0Lja6XJ1MZyNtYSicY/edit?usp=sharing
16:33:37 <winston-d> and let me know if you have any comment. it's 90% ready. Will do some cleanup
16:33:45 <avishay> winston-d: will this go into openstack-manuals?
16:33:51 <jgriffith> winston-d: thanks for pointing that out
16:33:53 <kmartin> winston-d: +1 and thanks for all the work
16:33:59 <jgriffith> alright.. .anyone else?
16:34:04 <bswartz> winston-d: nice document
16:34:13 <jgriffith> lets wrap this up and move to #cinder
16:34:22 <avishay> sounds good
16:34:25 <jgriffith> #endmeeting