16:02:09 <jgriffith> #startmeeting cinder
16:02:11 <smcginnis> El diablo!
16:02:11 <openstack> Meeting started Wed Aug 19 16:02:09 2015 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:15 <openstack> The meeting name has been set to 'cinder'
16:02:20 <Swanson> hi
16:02:24 <xyang2> hi
16:02:26 <geguileo> Hi
16:02:26 <ericksonsantos> hi
16:02:27 <smcginnis> o/
16:02:27 <jungleboyj> Hello all.
16:02:29 <dannywilson> hi
16:02:29 <jseiler__> HI
16:02:30 <eharney> hi
16:02:32 <scottda> hey
16:02:32 <thangp> o/
16:02:33 <jgregor1> Hello
16:02:35 <patrickeast> hi
16:02:36 <jgriffith> xyang2: around?
16:02:38 <schwicke> hi
16:02:41 <xyang2> yes
16:02:43 <diablo_rojo> hello
16:02:47 <jungleboyj> smcginnis: Saved by the bell.
16:02:48 <jgriffith> #topic Non-disruptive backups
16:02:50 <schwicke> (I'm new here)
16:02:57 <xyang2> https://review.openstack.org/#/c/204232/
16:03:10 <xyang2> this is the CLI patch for non-disruptive backup
16:03:11 <jgriffith> welcome schwicke
16:03:24 <xyang2> There's a review comment regarding the force flag
16:03:30 <jungleboyj> Welcome schwicke !
16:03:36 <xyang2> used for backup in-use volume
16:03:41 <geguileo> schwicke: Welcome
16:04:02 <xyang2> So this flag was added when the first server side patch was reviewed.
16:04:07 <jgriffith> xyang2: I'd agree WRT to the flag name
16:04:18 <jgriffith> xyang2: can we change it?
16:04:35 <xyang2> Also I see that snapshot a in-use volume uses the same force flag
16:04:40 <DuncanT> --force is already used in snapshot, with identical semantics
16:04:47 <xyang2> should we be consistent
16:04:53 <eharney> --force for snapshots is a terrible wart IMO
16:04:53 <DuncanT> +1 on consistency
16:04:57 <xyang2> DuncanT +1
16:05:01 <jgriffith> xyang2: DuncanT eharney can we just move forward with force then, deprecate it and fix *all* of them in M?
16:05:04 <tbarron> hi
16:05:15 <DuncanT> jgriffith: +1
16:05:16 <xyang2> jgriffith: fine with that
16:05:20 <eharney> i don't have a problem with force in the API (at least not a big problem)
16:05:20 <smcginnis> jgriffith: +1
16:05:22 <hemna> so, doesn't this require the volume to be multi-attached to be able to backup (mount) an in-use volume ?
16:05:31 <eharney> i'm just pointing out that i don't think that this is the interface we really want at the client
16:05:32 <jgriffith> eharney: LOL
16:05:37 <DuncanT> hemna: No, it uses a snapshot
16:05:38 <geguileo> eharney: +1
16:05:49 <xyang2> hemna: no requirement on multiattach
16:05:58 <tbarron> eharney: +1, we really over-use that word
16:06:01 <geguileo> xyang2: What happens if the client always sends force=True?
16:06:16 <DuncanT> eharney: I'm fine with a patch now that fixed both snap and backup, leaving --force as a depricated option in the client... I'm not ok with inconsistency
16:06:18 <geguileo> xyang2: Will it work for available volumes?
16:06:18 <xyang2> geguileo: no problem, it will back it up
16:06:20 <jgriffith> eharney: geguileo I see your point except that it is true we use this terminology *everywhere* for similar things
16:06:20 <hemna> xyang2, so it snaps, then mounts a volume from the snap to do the backup? then nukes the volume from the snap and the snap?
16:06:27 <xyang2> geguileo: yes
16:06:39 <geguileo> xyang2: eharney Then client just has to always send force=True
16:06:40 <DuncanT> hemna: Yes
16:06:44 <eharney> DuncanT: i'm not convinced an option is actually needed for backup
16:06:55 <hemna> DuncanT, ok, then yah, why do we even need a --force then?
16:06:55 <DuncanT> hemna: There's patches in progress that fast-path it where possible
16:07:00 <xyang2> geguileo: if it is in-use only
16:07:04 <geguileo> eharney: And that should resolve the issue, right?
16:07:11 <jgriffith> eharney: ahh... you're proposing just make it the default
16:07:14 <eharney> geguileo: that, or retry w/ force based on an error
16:07:24 <eharney> jgriffith: not necessarily, but maybe
16:07:27 <guitarzan> hemna: because snapshotting in use data is "at your own risk"
16:07:28 <geguileo> jgriffith: I hve no problem with force on the API, it's the client part
16:07:34 <DuncanT> eharney: Consistency with snap is my argument
16:07:40 <geguileo> jgriffith: That the user needs to try to backup and the add --force
16:07:44 <geguileo> jgriffith: It should be automatic
16:07:56 <eharney> DuncanT: i don't like that argument because requiring force for snapshots in the common case has stuck out to me as something that's really annoying for years now
16:07:56 <DuncanT> geguileo: Offline backup and online backup are different
16:07:58 <xyang2> geguileo: how can you use it in api without adding to client?
16:08:09 <eharney> DuncanT: but i understand what you're saying
16:08:13 <jgriffith> geguileo: well, the client is what I'm discussing here
16:08:19 <geguileo> xyang2: I'm explaining it wrong
16:08:21 <DuncanT> geguileo: Change the default, and scripts that currently assume they will fail on an online volume will now behave differently
16:08:40 <geguileo> xyang2: If force=True works with an available volume as well as with an in-use volume
16:08:55 <geguileo> xyang2: Client just needs to send it always to True by default
16:09:10 <DuncanT> eharney: I don't at all object to a clean up, but it should be done consistently
16:09:15 <geguileo> xyang2: That way client user don't need to worry about volume status
16:09:21 <jgriffith> geguileo: I think that's what I just said and you mentioned something about "I don't care about the Api"
16:09:22 <DuncanT> geguileo: See above - the may break existing code
16:09:28 <eharney> DuncanT: i'm hoping to avoid making it more messy in the first place
16:09:35 <xyang2> geguileo: I don't understand that.  snapshot needs the same thing in client
16:10:00 <jgriffith> DuncanT: I'm not sure I buy the "break" existing code
16:10:13 <DuncanT> eharney: Fix up snap in the same patch for all I care, just don't release a library where the un-depricated option is --force for one and something else for another
16:10:13 <eharney> the usability for snapshot in the client is not a good example
16:10:18 <jgriffith> DuncanT: if we make it work in more cases than it used to that seems like a win to me
16:10:56 <DuncanT> jgriffith: Loop over all volumes calling backup for all of them, expecting only the detached ones to backup. People absolutely write code like that
16:11:03 <jgriffith> DuncanT: I don't know that I envision people saying "Hey... you allow online backups now, before you didn't... I'm pissed"
16:11:26 <jgriffith> DuncanT: seems like poor code.. but ok
16:11:38 <DuncanT> jgriffith: Far from the worst ccode out there, I promise
16:11:59 <jgriffith> DuncanT: I'm just saying that's what happens when you release new functionatlity
16:12:18 <jgriffith> DuncanT: so document it and say, "change your scripts to check status rather than relying on an exception"
16:12:25 <jgriffith> if they can't figure that out on their own
16:12:50 <geguileo> DuncanT: It's a good point, it has to be backward compatible  :-(
16:12:51 <jgriffith> But anyway... is this really that big of a wart?
16:13:00 <DuncanT> jgriffith: It's a support headache, and a library API break - with semantic verisoning you'd need a new major number
16:13:03 <jgriffith> geguileo: it IS backward compatible!!!
16:13:16 <jgriffith> this isn't a matter of compatibility of API change
16:13:19 <jgriffith> But regardless
16:13:19 <geguileo> jgriffith: If we do it with --force yes
16:13:20 <DuncanT> jgriffith: No, it is NOT backwards compatiable
16:13:25 <jgriffith> OMG
16:13:27 <geguileo> jgriffith: If we do how I wanted to do it NO  XD
16:13:39 <jgriffith> Ok... back to the question; can we just live with the force flag then?
16:13:44 <guitarzan> you can't just autoforce snapshots/live backups
16:13:46 <DuncanT> jgriffith: Backwards compatability includes negative cases too
16:13:48 <guitarzan> teh client has to specify it
16:13:57 <guitarzan> otherwise we'll just mess up everyone's data
16:13:59 <geguileo> jgriffith: Yes, I think we can/must/have to
16:14:05 <eharney> one relevant point about what we do with this for now is how people will feel about someone working on this as an enhancement later
16:14:14 <thingee> o/
16:14:14 <jgriffith> guitarzan: no DuncanT and geguileo propose that is breaking backward compat
16:14:28 <erlon> hi
16:14:33 * thingee is present at openstack operators sprint
16:14:37 <guitarzan> jgriffith: right, I'm not asking, I'm saying --force *has* to stay
16:14:44 <jgriffith> guitarzan: ahh
16:14:48 <guitarzan> otherwise you're just going to blow up everyone's snapshots/backups
16:14:58 <eharney> guitarzan: why is that?
16:14:59 <guitarzan> "Why are all my snapshots/backups corrupted?"
16:15:08 <guitarzan> because they're live
16:15:11 <guitarzan> they're in use
16:15:12 <geguileo> guitarzan: They wouldn't be corrupted
16:15:14 <guitarzan> they're being written to
16:15:24 <eharney> guitarzan: they will fail if the driver doesn't support doing this, not corrupt things
16:15:26 <DuncanT> guitarzan: +1
16:15:32 <guitarzan> eharney: it has nothing to do with the driver
16:15:36 <jgriffith> guitarzan: I think that's a question for the feature itself then
16:15:41 <guitarzan> it's a raw block device
16:15:44 <eharney> guitarzan: i'm not following then...
16:15:48 <jgriffith> guitarzan: DuncanT and if that's the case I think force is absolutely fine
16:15:52 <DuncanT> eharney: Crash consistent snaps are totally different to clean snaps
16:15:56 <jgriffith> and the correct term
16:16:10 <eharney> haaang on... what's the path that leads to corruption?
16:16:30 <hemna> eharney, snapping an attached volume
16:16:30 <DuncanT> eharney: Expecting an unmounted FS or an error, and getting crash consistent
16:16:37 <guitarzan> eharney: partial write + snapshot + continued partial write
16:17:01 <eharney> that's a discussion for whether we should be doing this feature at all, not the client interface, it sounds like to me?
16:17:12 <guitarzan> no, it's totally a useful feature
16:17:21 <guitarzan> it just has to be coordinated by the guest
16:17:27 <DuncanT> eharney: some filesystems and some apps are fine with it, others aren't
16:17:29 <guitarzan> "Hey, I know what I'm doing, take a snapshot now"
16:17:32 <jgriffith> eharney: agreed... which make the term "force" seem more appropriate to me
16:17:33 <eharney> so you want --force because you say it needs to be delimited as something that's dangerous
16:17:44 <guitarzan> it is absolutely dangerous
16:17:44 <DuncanT> eharney: +1
16:17:45 <hemna> eharney, I think that's the idea yah
16:17:57 <eharney> i don't know what my opinion is on that, but i understand the point
16:18:14 <jungleboyj> guitarzan: That seems appropriate to me.
16:18:16 <eharney> i don't remember the help text in the client saying anything about that...
16:18:36 <DuncanT> eharney: File a bug, that's easy to fix/improve
16:18:46 <jgriffith> Ok... so force it is?
16:18:55 <geguileo> jgriffith: I think so
16:18:59 <jgriffith> can we all agree on that and move on?
16:19:07 <hemna> yah
16:19:07 <xyang2> DuncanT: client side is not merged.  So I can improve the help message
16:19:08 <guitarzan> yes please
16:19:09 <eharney> i guess --force and we need to extend what the help text says
16:19:13 <eharney> i don't know why i'd file a bug for this
16:19:14 <hemna> if we don't pass in force then this happens: https://github.com/openstack/cinder/blob/master/cinder/volume/api.py#L685-L690
16:19:29 <DuncanT> eharney: I meant the snap help text that has been there forever
16:19:33 <jgriffith> xyang2: anything else?
16:19:37 <eharney> hemna: force at the API level is a lot different from making the user type --force
16:19:40 <eharney> DuncanT: ah gotcha
16:19:40 <jungleboyj> jgriffith: Makes sense to me.  GO with the safest route.
16:19:55 <xyang2> jgriffith: all set.  I'll update the patch with a better help msg
16:20:05 <jgriffith> xyang2: great, thanks xyang2
16:20:15 <jgriffith> and eharney DuncanT geguileo guitarzan for the insights
16:20:17 <xyang2> thanks
16:20:46 <jgriffith> #topic open-discussion
16:20:50 <hemna> eharney, meh, the reasons we have force there at all are because we wanted the user to type it, for good reasons, so I don't see that as much of a distinction really.
16:20:50 <thingee> just a reminder
16:20:55 <thingee> https://etherpad.openstack.org/p/cinder-liberty-3-reviews
16:21:07 <thingee> those are the priority reviews. please grab some stuff to test and review
16:21:19 <schwicke> that's why I'm here :)
16:21:23 <thingee> I will be contacting folks on getting documentation updated for some of these.
16:21:23 <eharney> hemna: the problem was, we didn't write down the good reasons anywhere
16:21:51 <thingee> Cinder got a shout out at the Cinder midcycle sprint as an example for other projects in how release notes should be
16:22:02 <hemna> thingee, nice
16:22:05 <thingee> people really appreciated documentation links to go with items on the list
16:22:06 <smcginnis> Which midcycle?
16:22:15 <jgriffith> smcginnis: :)
16:22:16 <thingee> smcginnis: ops midcycle sprint
16:22:20 <jgriffith> you caught that too
16:22:20 <smcginnis> :)
16:22:25 <smcginnis> Cool!
16:22:43 * thingee noted earlier he's at ops midcycle
16:23:01 <jgriffith> thingee: said "Cinder got a shout out at the Cinder midcycle sprint"
16:23:15 <thingee> 09:14 — thingee is present at openstack operators sprint
16:23:17 <thingee> jgriffith: ^
16:23:23 <jgriffith> thingee: LOL
16:23:29 <thingee> anyways
16:23:32 <jgriffith> thingee: I don't think you get it
16:23:32 <jgriffith> never mind
16:23:40 <thingee> also jgriffith will be my eyes and ears the next couple of weeks
16:23:40 <jgriffith> smcginnis: got it
16:23:55 <thingee> I will be MIA for two weeks in some desert
16:24:01 <smcginnis> The puppet master. :P
16:24:11 <hemna> thingee, we want picts of the bus.
16:24:34 <thingee> I fully expect on August 24th for jgriffith and core to be giving -2's on patches that meet the criteria http://lists.openstack.org/pipermail/openstack-dev/2015-August/071505.html
16:24:50 <thingee> and for us to be in a very limited bug fix mode when I come back in september
16:24:51 <jungleboyj> hemna: ++
16:25:07 <thingee> I will be back September 7th
16:25:11 * jgriffith wonders what we'll all do for 2 months :)
16:25:35 <smcginnis> Lots of testing.
16:25:38 <smcginnis> :)
16:25:40 <jgriffith> thingee: what does "limited" mean Captain?
16:25:48 <hemna> smcginnis, testing?  what is that....
16:25:55 <thingee> bug fixes, testing
16:26:01 <smcginnis> pep8 passes... ship it.
16:26:07 <thingee> smcginnis: +1
16:26:09 <jgriffith> smcginnis: LOL
16:26:09 <DuncanT> jgriffith: It's a bug that my array isn't supported, here's a patch to fix it
16:26:11 <hemna> smcginnis, winning!
16:26:21 <jgriffith> DuncanT: ahh... you mean the usual
16:26:23 <smcginnis> DuncanT: Hah!
16:26:27 <dannywilson> lol
16:26:33 <jungleboyj> smcginnis: It worked in devstack!
16:26:48 <DuncanT> jgriffith: Also, can I backport it to diablo tree?
16:26:59 <thingee> that's all for me.
16:27:04 <jungleboyj> DuncanT: Sure!
16:27:04 <bswartz> thingee: when you say things need to be in passing before the 24th that means the actual freeze is 23:59 UTC on August 23rd, right?
16:27:08 <jgriffith> Ok... does anybody have anything we need to talk about as a team?  Or should we get an extra 35 minutes to do reviews :)
16:27:34 <thingee> bswartz: it means it had to have passed jenkins before then. merge conflicts can be resolved
16:27:49 <smcginnis> I'll just state here I'm seeing CI weirdness. Hope it's not just me.
16:27:54 <thingee> oh and welcome geguileo to cinder core folks
16:28:03 <smcginnis> geguileo: Congrats!
16:28:06 <bswartz> okay -- just clarifying because some might have thought 23:59 UTC on the 24th was the deadline
16:28:19 <jgriffith> indeed congrats geguileo on the fastest core promotion in
16:28:21 <geguileo> Thanks!!
16:28:23 <jgriffith> cinder history!
16:28:30 <hemna> :)
16:28:52 <jgriffith> Ok,,, thingee you have anything else?
16:29:00 <jungleboyj> geguileo: Congrats!
16:29:02 <thingee> jgriffith: nope, thanks
16:29:12 <jgriffith> bswartz: I don't know that he answered your question?
16:29:12 <geguileo> jungleboyj: Thanks
16:29:34 <jgriffith> <bswartz> okay -- just clarifying because some might have thought 23:59 UTC on the 24th was the deadline
16:29:35 <bswartz> jgriffith: he did
16:30:00 <bswartz> it was mostly clarification for other people
16:30:19 <jgriffith> "before then" meaning 23:59 the 23?  or the 24th?
16:30:33 <bswartz> I think that thingee said is perfectly clear -- the deadline is the night of the 23rd
16:30:35 <hemna> 23:59:59
16:30:44 <jgriffith> hemna: :)
16:30:44 <thingee> bswartz: +1
16:30:47 <bswartz> the email isn't so crystal clear
16:30:54 <schwicke> ok, thnaks for the clarification!
16:31:02 <jgriffith> alright, thanks everyone
16:31:04 <thingee> bswartz: I ran it by people before I sent it out at the cinder midcycle :P
16:31:08 * thingee blames xyang1
16:31:10 <thingee> ;D
16:31:14 <jgriffith> #endmeeting