16:01:24 <jgriffith> #startmeeting cinder
16:01:25 <openstack> Meeting started Wed Jul  9 16:01:24 2014 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:29 <openstack> The meeting name has been set to 'cinder'
16:01:30 <jgriffith> Hey everybody
16:01:31 <bswartz> hi
16:01:35 <winston-d_> hi
16:01:37 <avishay> https://wiki.openstack.org/wiki/CinderMeetings
16:01:38 <jungleboyj> Hello.
16:01:40 <avishay> hi
16:01:41 <jkremer> hi
16:01:55 <ameade> hello
16:01:55 <glenng> Greetings!
16:02:02 <jgriffith> #agenda https://wiki.openstack.org/wiki/CinderMeetings
16:02:26 <DuncanT-> hey
16:02:29 <jgriffith> #topic status of connector seperation from drivers (flip214)
16:02:29 <xyang1> hi
16:02:47 <flip214> well, okay.
16:02:53 <jgriffith> #link https://review.openstack.org/#/c/104701/
16:02:55 <anteaya> o/
16:03:05 <flip214> grrg, just when I'm about to ask.
16:03:15 <flip214> we need to establish a token ring here.
16:03:19 <jgriffith> flip214: the "new" model works with TgtADM, LIO on LVM
16:03:26 <jgriffith> flip214: I don't have a way to test/fix ISER
16:03:31 <jgriffith> flip214: yet at least
16:03:43 <flip214> but would you say it's in a state that I could start putting replication in there?
16:03:54 <xyang1> what about FC?
16:03:54 <flip214> or is it about to change so much that I'll only get merge conflicts later on?
16:03:58 <jgriffith> need to run a check on IET... and barring any more freak outs I'd like to remove the wip and get it moving forward
16:04:06 <jgriffith> xyang1: one step at a time :)
16:04:15 <xyang1> jgriffith: sure
16:04:17 <bswartz> who is doing the NFS work?
16:04:19 <jgriffith> xyang1: I'd like to implement the LVM / FC next
16:04:23 <jgriffith> bswartz: you
16:04:24 <jgriffith> :)
16:04:31 * bswartz looks surprised
16:04:36 <jgriffith> bswartz: LOL
16:04:46 <bswartz> okay thanks for the heads up
16:04:50 <jgriffith> bswartz: I may or may not get to it
16:04:59 <bswartz> I'm happy to help
16:05:09 <jgriffith> bswartz: flip214 the point I tried to make previously is I don't intend to just "break" all of the existing code
16:05:15 <jungleboyj> bswartz: We have a guy here at IBM that was looking at working on that as well.
16:05:19 <jgriffith> just start movement to a sane architecture
16:05:20 <bswartz> how soon can groundwork get merged ?
16:05:44 <jgriffith> bswartz: if folks are happy with it I can finish it up and get moving today/tomorrow
16:06:09 <jgriffith> I just need to decide the best way to have both models co-exist
16:06:18 <jgriffith> the "new_drivers" dir is certainly an option
16:06:18 <xyang1> jgriffith: are we going to change every driver in stages?
16:06:25 <flip214> jgriffith: so I could start working with that, say, next week?
16:06:40 <jgriffith> flip214: sure.. or later this week... or now
16:07:05 <jgriffith> flip214: I don't anticipate major changes to the principals of the design... just maybe some swapping of names
16:07:32 <jgriffith> might be good to switch over CI to use the new model for a bit and shake out any unexpected races etc
16:07:35 <avishay> i'm seeing this patch/blueprint for the first time now.  i guess i understand the LVM/iSCSI changes, but what do other drivers have to do?
16:07:39 <flip214> jgriffith: ack, thanks a lot. question answered, let's move on.
16:07:45 <rushiagr__> o/
16:08:22 <jgriffith> avishay: they don't have to necessarily do anything right now.  But it would probably be in their best interest to clean up their inheritance model
16:08:41 <xyang1> jgriffith: so every driver will inherite from the new base VolumeDriver class and set the correct connect?
16:08:45 <jgriffith> avishay: so rather than inherit iscsiDriver, just inherit Driver and your own connector etc
16:08:46 <xyang1> connector
16:08:49 <jgriffith> or one of the existing ones
16:08:56 <avishay> jgriffith: gotcha
16:08:57 <jgriffith> xyang1: yup
16:09:10 <avishay> sounds more gooder
16:09:18 <jgriffith> avishay: I thought it would be
16:09:30 <jgriffith> avishay: and it offers a good deal of flexibility
16:09:45 <jgriffith> avishay: ie inherit iscsi connector, override at will
16:09:49 <avishay> agreed
16:09:52 <flip214> jgriffith: so for things that use the replication api ... these need to be between eg. lvm and iscsi
16:10:02 <flip214> should the replication api implementation be "just" something that can be mixed in additionally?
16:10:05 <xyang1> jgriffith: so we will ask each driver maintainer to move to this new model, right?
16:10:10 <jgriffith> xyang1: I am starting to mess with creating FC targets and going down that path
16:10:25 <avishay> jgriffith: solidfire has FC now?
16:10:26 <xyang1> jgriffith: have fun:)
16:10:26 <jgriffith> xyang1: getting fc gear for extended periods of time is tricky though
16:10:39 <jgriffith> avishay: sadly we are going down that path yes
16:10:41 * jgriffith hates FC
16:10:45 <avishay> jgriffith: :)
16:10:54 <jgriffith> trrible legacy tech that should DIE
16:11:00 <jgriffith> terrible even
16:11:06 <avishay> how is replication related to this?
16:11:33 <jgriffith> avishay: not sure it is?
16:11:38 <flip214> avishay: I'd guess that the replication driver(s) should be available for lvm-iscsi, lvm-fc, and so on.
16:11:39 * jungleboyj likes tribble legacy tech better.
16:11:50 <flip214> so they'd be a level in-between the storage and the connector.
16:12:08 <kmartin> jgriffith:  +1 for FC :)
16:12:22 <jgriffith> kmartin: for making it DIE or that you like it :)
16:12:36 <avishay> flip214: OK, think i get where you're going
16:12:49 <kmartin> long live FC, +1 for the solidfire FC driver
16:12:55 <jgriffith> flip214: avishay I see replication as still very much in progress so not sure
16:12:59 <jgriffith> kmartin: damn you!
16:13:01 <jgriffith> :)
16:13:04 <xyang1> kmartin: +1:)
16:13:07 <avishay> next topic?
16:13:12 <jgriffith> avishay: yes please
16:13:17 <thingee> o/
16:13:21 <avishay> jgriffith: agreed
16:13:26 <avishay> thingee: hello!
16:13:30 <xyang1> jgriffith: timeline for the move?
16:13:32 <jgriffith> #topic batching up cleanup patches
16:13:32 <asselin> hi
16:13:39 <jgriffith> DuncanT-: I'm assumign that's you?
16:13:43 <DuncanT-> Aye
16:13:53 <avishay> DuncanT-: text looks OK to me
16:14:04 <winston-d_> avishay: +1
16:14:06 <DuncanT-> Really simple question: Does anybody hate the text enought o complain?
16:14:13 <anteaya> I think we want status:open instead of status:merged in the linked gerrit query
16:14:24 <kmartin> +1, text looks fine to me
16:14:26 <DuncanT-> anteaya: -status:merged
16:14:33 <DuncanT-> The negation is important
16:14:40 <jgriffith> anteaya: that's a "not" merged
16:14:45 <jgriffith> Oh... yeah.. what DuncanT- said
16:14:47 <DuncanT-> And less to type than status:open OR status:abandoned
16:14:50 <jgriffith> dang IRC races
16:15:22 <anteaya> DuncanT-: okay
16:15:22 <DuncanT-> The query now seems to be finding the right patch (thanks flip214 / jgriffith for the help)
16:15:36 <anteaya> yes, while status:open doesn't for some reason
16:15:38 <anteaya> how odd
16:15:45 <DuncanT-> Ok, I'm done :-)
16:16:03 <DuncanT-> We can make the search smarter later if we need to
16:16:05 <flip214> DuncanT-: perhaps use a different character than "-" ... something sane, like ø might do ;)
16:16:16 <jgriffith> FTR I think it's a great idea
16:16:22 <DuncanT-> flip214: I used underscore - already done :-)
16:16:24 <jgriffith> Thx DuncanT- for proposing it
16:16:32 <avishay> uh oh...we have 44 minutes left...
16:16:38 <jungleboyj> DuncanT-: Somehow I missed this.
16:16:47 <winston-d_> fastest meeting ever!
16:16:47 <jgriffith> let's quit while we're ahead :)
16:16:52 <jgriffith> #topic J2
16:17:00 <jgriffith> Just a reminder
16:17:02 <jgriffith> J-2 is upon us
16:17:05 * avishay jinxed it
16:17:10 <jungleboyj> DuncanT-: Nevermind, will chat after the meeting.
16:17:15 <jgriffith> avishay: promise just a minute on this
16:17:24 <ameade> I don't like the idea
16:17:28 <jgriffith> Jly 24 is release
16:17:44 <ameade> for the batching i mean
16:17:55 <jgriffith> Next week I'll freeze any spec submissions
16:18:08 <xyang1> jgriffith: You've approved a few cinder specs.  can you also update the blueprint milestone for J-2?
16:18:09 <DuncanT-> ameade: jungleboyj: Looks like we'll have to come back to this in a sec
16:18:25 <jgriffith> xyang1: yes, please be patient
16:18:35 <xyang1> jgriffith: sure.  thanks!
16:18:38 <jgriffith> or I'll go back and revert the specs :)
16:18:47 <jgriffith> crap
16:18:53 <jgriffith> ok.. ameade jungleboyj what's the problem?
16:18:59 <xyang1> jgriffith: ok, I'll be quiet:)
16:19:04 <jgriffith> xyang1: :)
16:19:07 <eharney> jgriffith: can you say something about specs expectations for blueprints that have existed for a while
16:19:13 <ameade> if we do that all it's going to do is deter people from writing cosmetic patches.
16:19:28 <jgriffith> eharney: yeah... if you had a bp prior to specs don't worry about writing a spec
16:19:37 <jgriffith> eharney: also... every change doesn't need a spec
16:19:38 <eharney> is that dependent on it being marked as approved or something?
16:19:47 <ameade> is it really a big problem to rebase on top of cosmetic changes?
16:19:49 * eharney needs to go cleanup some blueprints
16:19:51 <jgriffith> eharney: nahh... IMO just timing
16:20:12 <jgriffith> eharney: seem fair?
16:20:19 <eharney> yeah
16:20:19 <jungleboyj> jgriffith: DuncanT- I just want to make sure I understand.  Anything that isn't fixing a bug, is just cleaning up or something like that we should follow the process from DuncanT- ?
16:20:23 <jgriffith> eharney: we still have some learning and fine tuing WRT specs anyway
16:20:36 <jungleboyj> DuncanT-: So a change like fixing typos, etc.
16:20:47 <avishay> jgriffith: it would be nice if there was a way to know which code patches belong to blueprints that are not yet approved and give lower priority...no idea if that's possible
16:21:16 <eharney> avishay: we haven't historically used "approval" enough for that to matter... are we now?
16:21:17 <jgriffith> avishay: you can click on the "implements blueprint: xxx" link
16:21:40 <jungleboyj> jgriffith: eharney I found a patch yesterday that was associated with a Blueprint from may with no spec.  I noted it needed a spec.  That seem right?
16:21:42 <jgriffith> avishay: eharney oh... think I see what you're saying
16:21:50 <jgriffith> jungleboyj: nope
16:21:55 <DuncanT-> jungleboyj: Basically this comes down to the taste of the cores...
16:21:55 <jgriffith> not necessarily
16:22:04 <eharney> jungleboyj: kind of a problem if i submit code like that after the spec freeze
16:22:06 <winston-d_> ameade: not for every clean-up patches, but for some, for example: https://review.openstack.org/#/c/104493/ if this landed right before J2, it may create a rebase hell
16:22:07 <jgriffith> like I said it's a learning process
16:22:32 <jgriffith> I'd like to see specs used for:
16:22:42 <jgriffith> 1. Things that modify the API (add, change etc)
16:22:50 <jungleboyj> DuncanT-: Ok.  Whatever we deem to be clean up.  Ok.
16:22:50 <jgriffith> 2. Major features
16:23:19 <DuncanT-> jungleboyj: And only really cleanup that is likely to cause rebase pain - see John's excellent example
16:23:20 <jgriffith> mostly things that change the behavior or end user experience
16:23:25 <avishay> 3. Drivers?
16:23:33 <jgriffith> avishay: I'm mixed on that
16:23:35 <jungleboyj> DuncanT-: Ok.  THanks.
16:23:35 <ameade> winston-d_: I doubt that example would create rebase hell, the worst patches would be moving giant chunks of code
16:23:45 <jgriffith> avishay: I find it somewhat unnecessary overhead
16:23:51 <eharney> IMO most driver work doesn't seem to call for a spec
16:23:53 <thingee> jgriffith: +1
16:23:55 <jgriffith> it's boiler plate in almost every case
16:24:07 <thingee> "I plan to write a driver with minimum cinder requirements"
16:24:09 <thingee> BOOM
16:24:15 <jgriffith> thingee: +1
16:24:16 <eharney> thingee: exactly
16:24:25 <avishay> for "classic" drivers yes, but lately there have been some drivers that got pushback
16:24:31 <xyang1> jgriffith: so a new driver needs a spec but enhancements to an existing driver doesn't need spec?
16:24:39 <jgriffith> avishay: don't get me started if you want to end this meeting :)
16:24:44 <avishay> jgriffith: :)
16:24:46 <jgriffith> xyang1: neither
16:24:55 <jgriffith> xyang1: drivers don't need spes is my proposal
16:25:02 <xyang1> jgriffith: okay, that will be easier
16:25:16 <avishay> jgriffith: let's have a philosophical discussion on the role of drivers in cinder
16:25:26 * jgriffith slaps avishay
16:25:29 <avishay> haha
16:25:35 <thingee> oh dear
16:25:51 <jgriffith> Ok... any burning concerns?
16:25:58 <jgriffith> itchiness... rashes?
16:26:02 * jungleboyj laughs.
16:26:04 <jgriffith> swelling?
16:26:11 <anteaya> I'm sneezing a lot
16:26:13 <kmartin> jgriffith: what about a spec for "Separate data-path cmds from control cmds" ? that seemed to throw some people for a loop
16:26:21 <DuncanT-> If a reviewer *really* feels a change would benefit for the spec process, I don't think it is unreasonable to ask for one (e.g. the private types recently... the spec has definitely helped me become happy with the idea fast)
16:26:31 * jungleboyj has a strange rash ...  ;-)
16:26:38 <jgriffith> anteaya: hmmm... could be allergies
16:26:40 <DuncanT-> kmartin: We did that earlier
16:26:42 <avishay> *cough* TMI *cough*
16:27:26 <DuncanT-> anteaya: tourniquet to the throat will fix your cough
16:27:32 <avishay> lol
16:27:33 <jungleboyj> So, specs not required for driver changes just required for changes that touch the larger user base.
16:27:38 <anteaya> DuncanT-: gee, thanks
16:27:49 <avishay> ok i think we're about to be kicked out of the room
16:28:04 <DuncanT-> anteaya: It's kind of a universal elixir like that
16:28:12 <DuncanT-> avishay: ??? We have half an hour
16:28:17 <anteaya> DuncanT-: helpful
16:28:27 <avishay> DuncanT-: i know, but we're done and was hoping nobody would notice
16:28:39 <jungleboyj> DuncanT-: avishay is really trying to finish this.
16:28:43 <jgriffith> avishay: +1
16:29:08 <jgriffith> alright.. should we wrap this up?
16:29:12 <xyang1> jgriffith: can I have a code review request since we are done?
16:29:16 <xyang1> https://review.openstack.org/#/c/104732/
16:29:18 <thingee> jgriffith: yes!
16:29:19 <jgriffith> jungleboyj: DuncanT- can clarify in openstack-cinder
16:29:24 <jgriffith> xyang1: no
16:29:24 <xyang1> CG changes
16:29:25 <jgriffith> :)
16:29:30 <jgriffith> thanks everyone!
16:29:33 <avishay> xyang1: only 2500 LOC, no sweat!
16:29:33 <jgriffith> #endmeeting