16:00:45 <jgriffith> #startmeeting cinder
16:00:46 <openstack> Meeting started Wed May 22 16:00:45 2013 UTC.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:49 <openstack> The meeting name has been set to 'cinder'
16:00:56 <thingee> o/
16:01:19 <jgriffith> Note agenda #link https://wiki.openstack.org/wiki/CinderMeetings
16:01:43 <jgriffith> #topic H1 freeze date
16:01:55 <jgriffith> So just FYI freeze for H1 is Next Tuesday
16:02:05 <rushiagrawal> Hi all
16:02:15 <cian_> Hi
16:02:16 <jgriffith> hello rushiagrawal
16:02:21 <jgallard> hi all
16:02:29 <jgriffith> o/
16:02:29 <xyang_> jgriffith: so the patch has to be merged by next Tuesday, right
16:02:30 <avishay> Hi
16:02:33 <winston-d> hi
16:02:36 <jgriffith> xyang_: correct
16:02:36 <xyang_> hi
16:02:48 <jgriffith> xyang_: which leads me to my question for you :)
16:03:02 <jgriffith> xyang_: do you think you'll get through the legal team by then?
16:03:11 <hemna> morning
16:03:13 <jgriffith> xyang_: we can always defer to H2
16:03:18 <bswartz> good afternoon
16:03:20 <jgriffith> not a big deal at all
16:03:21 <dachary> hi
16:03:23 <avishay> good evening
16:03:34 <xyang_> jgriffith: I'm still waiting.  Can I get back to you later today
16:03:43 <jgriffith> xyang_: sure, that's fine
16:03:59 <jgriffith> winston-d: around?
16:04:08 <winston-d> jgriffith: yup!
16:04:35 <jgriffith> I think you're rate limiting BP is pretty close (at least for the Cinder side) and first portion
16:05:05 <jgriffith> winston-d: shoot..wrong bp
16:05:07 <jgriffith> :)
16:05:16 <jgriffith> scheduler hints :)
16:05:51 <jgriffith> winston-d: should we change the owner on that?
16:06:19 <jgriffith> For those wondering what I'm talking about: https://review.openstack.org/#/c/28945/
16:06:25 <winston-d> jgriffith: yes, please change to mirantis folk
16:06:26 <dachary> thanks
16:06:52 <jgriffith> winston-d: I went through it again last night, I think they covered the concerns folks raised
16:07:12 <jgriffith> winston-d: I think it's ready to go but needs another good going over by me an at least one or two others
16:07:17 <winston-d> jgriffith: there's something else needs fix. i'll post comments
16:07:34 <jgriffith> winston-d: I suspected that might be the case :)
16:07:34 <thingee> the concern I had with it that I haven't raised is whether it has to touch v2/volume.py if it's using the wsgi.extend decorator
16:08:21 <jgriffith> thingee: interesting
16:08:40 <thingee> I haven't looked closely at how wsgi.extend works, but I wanted to play with the patch to see if it's necessary
16:08:57 <thingee> if I drop the ball on this, I can always change it later.
16:09:02 <jgriffith> thingee: I don't know how that would work, but if you want to look at that, that's great
16:09:12 <winston-d> :)
16:09:19 <jgriffith> thingee: we've got time so that's fine by me
16:09:33 <jgriffith> thingee: you might want to ask the Mirantis folks if they've already thought/looked at that
16:10:31 <jgriffith> So most of the other things for H1 are on me :(
16:10:33 <jgriffith> https://launchpad.net/cinder/+milestone/havana-1
16:10:55 <jgriffith> But.. if anybody has some cycles, there are a few bugs that aren't asigned or triaged
16:11:25 <jgriffith> Any volunteers?
16:11:31 <jgriffith> thingee: you can't volunteer!
16:11:44 <winston-d> jgriffith: i'll take a look
16:11:50 <jgriffith> winston-d: thanks
16:11:55 * thingee needs to pull more all nighters
16:12:02 * hemna needs to clone himself
16:12:17 <hemna> I'm kinda slammed at the moment
16:12:17 <jgriffith> bswartz: any update on 1139129?
16:12:21 <thingee> https://bugs.launchpad.net/cinder/+bugs?orderby=status&start=0
16:12:34 * medberry will look a the queue but likely isn't ready to actually triage yet
16:12:45 <bswartz> which 1139129?
16:12:46 <jgriffith> medberry: thanks Dave
16:12:54 <jgriffith> bswartz: your bug targetted for H1
16:13:18 <bswartz> no update sorry
16:13:22 <jgriffith> bswartz: med_ et'all  https://launchpad.net/cinder/+milestone/havana-1
16:13:33 <jgriffith> I'm most interested in the items that are targetted for H1
16:13:49 <jgriffith> The link above is items that we *said* we'd have done for H1 including bugs
16:13:59 <jgriffith> bswartz: any idea when you might have an update?
16:14:02 <med_> nod
16:14:22 <bswartz> jgriffith: that one hasn't fallen off my radar, it just hasn't been a high enough priority
16:14:28 <jgriffith> bswartz: I've already removed your unified driver, sounds like that hasn't gone anywhere either?
16:14:29 <bswartz> I'll plan on H2
16:14:39 <jgriffith> bswartz: K, I'll adjust
16:14:41 <bswartz> jgriffith: the unified driver should be ready early in H2
16:15:01 <jgriffith> bswartz: Ok, although it was originally slated for H1
16:15:28 <jgriffith> bswartz: cool... updated
16:16:01 <avishay> jgriffith: I'm hoping bug 1122898 will be addressed by hemna's patch for H2 ("Refactor Cinder's iSCSI/FC attach code")
16:16:02 <uvirtbot> Launchpad bug 1122898 in cinder "Generic iSCSI copy volume<->image doesn't disconnect" [Undecided,Confirmed] https://launchpad.net/bugs/1122898
16:16:05 <jgriffith> Ok, anything folks see on that list they want to comment on before I ask some more questions about a few :)
16:16:32 <jgriffith> avishay: ok, so you want to retarget that one as well?
16:16:36 <lakhindr_> Jgriffith: is this the time to discuss the milestones of havana-1?
16:16:42 <avishay> jgriffith: yessir
16:16:53 <jgriffith> avishay: ko!
16:17:01 <jgriffith> lakhindr_: yes but hold on a moment
16:17:10 <jgriffith> I wanted to ask about the local disk stuff  :)
16:17:15 <med_> jgriffith, I'll take a look t 1161157
16:17:26 <med_> jgriffith, I'll take a look t 1161557
16:17:26 <jgriffith> med_: awesome possum
16:17:31 <hemna> avishay, subscribed to that one.   we'll have to test it with the refactor
16:17:40 <jgriffith> med_: if you *like* it, assign yourself pretty please :)
16:18:01 <jgriffith> https://blueprints.launchpad.net/cinder/+spec/local-disk-storage-utils
16:18:04 <avishay> hemna: yep, thanks :)
16:18:07 <jgriffith> so I threw that out there ^^
16:18:31 <jgriffith> Meanwhile we have: https://review.openstack.org/#/c/27051/
16:18:38 <jgriffith> Here's my question....
16:18:48 <avishay> yea...wanted to ask about that...
16:19:00 <jgriffith> Do folks see or hear of an advantage regarding using raw disks over LVM?
16:19:31 <bswartz> I see disadvantages
16:19:35 <eharney> seems unlikely, especially once you get to the snapshot features..
16:19:44 <avishay> jgriffith: apparently you - you wrote in the review "This is awesome and very much needed/requested as of late." :)
16:19:46 <hemna> LVM provides more flexibility in the usage of the raw disk no?
16:19:58 <avishay> jgriffith: but i don't have a use case for it personally
16:20:03 <med_> the hadoop argument (or similar) seems to be valid
16:20:07 <jgriffith> avishay: yes, and see my comments from last night... the point is I wanted to get input from others on this as well
16:20:33 <winston-d> i agree with med_ , performance concern could be one
16:20:57 <jgriffith> My testing doesn't show LVM taking that big of a hit on perf though which is why I wanted to bring this up
16:21:19 <jgriffith> LVM gets a bad wrap from folks like DuncanT :)
16:21:29 <bswartz> lol
16:21:32 <jgriffith> But that being said....
16:21:45 <jgriffith> Two folks pointing out a use case works for me
16:21:47 <avishay> LVM can have bad performance when dealing with snapshots and such, but I can't imagine it being too noticeable if you're using it like a disk
16:22:00 <jgriffith> avishay: not necessarily true either :)
16:22:08 <jgriffith> avishay: thin provisioning baby!!
16:22:22 <jgriffith> Ok... that's all I needed
16:22:26 <winston-d> maybe we can ask for some numbers from those folks
16:22:27 <avishay> jgriffith: I said "can" :)
16:22:32 <jgriffith> avishay: :)
16:22:52 <jgriffith> So if I'll figure out timing of Ann's patch versus the brick work
16:23:10 <jgriffith> Her patch my be just an "introduction" so to speak :)
16:23:23 <avishay> so what are the use cases?  i missed it?  hadoop?
16:23:38 <jgriffith> avishay: mostly just a perf thing
16:23:52 <jgriffith> avishay: TBH what started it was the bare metal stuff
16:24:05 <med_> jgriffith, my hadoop "expert" would really expect some optimizations in hadoop to do the wrong thing if on LVM....
16:24:09 <jgriffith> avishay: there's a real need for disk management fro Ironic and company
16:24:27 <avishay> jgriffith: gotcha
16:24:43 <jgriffith> kk
16:24:56 <jgriffith> so we covered H1 and status in one shot :)
16:25:03 <jgriffith> Moving along to lakhindr_
16:25:11 <lakhindr_> I am here :-)
16:25:13 <jgriffith> #topic Test code and example dirver files
16:25:20 <jgriffith> lakhindr_: I gave this it's own topic :)
16:25:24 <bswartz> jgriffith: can we discuss the share service briefly?
16:25:25 <hemna> :)
16:25:39 <jgriffith> bswartz: sure there's time at the end
16:25:44 <bswartz> okay
16:25:51 <jgriffith> bswartz: or right after this, I'll bump it up on the list :)
16:25:58 <bswartz> ty
16:26:07 <jgriffith> bswartz: yw
16:26:12 <jgriffith> Ok.. so: https://review.openstack.org/#/c/28791/
16:26:20 <jgriffith> For those of you that haven't been following
16:26:38 <jgriffith> There's a debate here and I think lakhindr_ would like to get some input
16:26:47 <jgriffith> So I'm going to give him 5 minutes to make his case :)
16:26:56 <jgriffith> Starting...  *NOW*
16:27:06 <hemna> time's up!
16:27:09 <lakhindr_> (Thanks Jgriffith: Folks, I have a proposal, which I wanted to mail, but then thought let me first try http://paste.openstack.org/show/37593/)
16:27:18 <lakhindr_> hemna: thanks :-)
16:27:21 <hemna> :)
16:27:29 <jgriffith> LULZ
16:28:01 <lakhindr_> I am here to briefly discuss what I have in mind. I can email it too. But basically I find merit in simulating our back-end compared to say mocking everything.
16:28:21 <lakhindr_> It has simplicity and power. And with that in mind, if you look at my code you can see how self tests are run.
16:28:29 <jgriffith> lakhindr_: I think folks get the point
16:28:41 <jgriffith> lakhindr_: and I don't think simulating/mocking the backend is the debate
16:28:43 <lakhindr_> Oh since you gave me 5 minutes, I thought I have to seak up :-)
16:28:58 <hemna> lakhindr_, the 3PAR unit tests "simulate" the back end (array) as well via a reimplemented client class
16:28:58 <lakhindr_> I was coming to that :-)
16:29:01 <jgriffith> lakhindr_: ok, sorry go ahead but I didn't want you to waste your 5 minutes :)
16:29:31 <avishay> the storwize/svc tests work against a simulator as well as real storage
16:29:43 <lakhindr_> Ah, so I have run afoul of some rules, e.g. where should a sample configuration file go. Some suggestion is, well don;t use it! But I prefer to.
16:30:04 <hemna> I think that's the crux of the -1's on the review
16:30:11 <lakhindr_> And the question of where it should go is I think easily resolved when a vendor subdirectory contains all the stuff in one place.
16:31:03 <jgriffith> lakhindr_: I thought it was resolved when we create block-storage-admin guide with driver config sections?
16:31:12 <jgriffith> s/create/created/
16:31:27 <thingee> lakhindr_: here's the issue I have with this. I want unit tests. I won't argue there is some gain in functional, but our tests are already slow with the mixture there is. I'd argue that your focus on your driver tests should be on the implementation, not if something can open a config.
16:31:32 <lakhindr_> Jgriffith. I am not saying anything about the admin guide. We shall of course abide by that.
16:32:04 <lakhindr_> My focus is on unit tests, thingee! And we are following all the requirements, indeed.
16:32:19 <lakhindr_> And of course focus is on the driver actually! Config is part of it!
16:32:57 <jgriffith> sighhh...  I fear there's no compromise here
16:33:06 <avishay> What's up with the separate config file trend instead of cinder.conf?
16:33:23 <lakhindr_> avishay: that is too simple.
16:33:23 <jgriffith> lakhindr_: I suspect what's going to happen:  Folks will keep -1 your patch until you at least attempt to address the points they've made
16:33:42 <avishay> lakhindr_: what is too simple?
16:34:06 <hemna> the confusion I believe is that other driver's also have their sample configs in place....which set a bad precedent.
16:34:09 <lakhindr_> avishay: as array configuration becomes more sophisticated they run beyond the scope of simple one liner config parameters
16:34:11 <thingee> lakhindr_: can you tell me the problem with the current things provided to the drivers that are in cinder?
16:34:37 <hemna> lakhindr_, that's what documentation is for IMHO
16:34:42 <avishay> hemna: i know, that's why i'm asking why people started with this craziness :)
16:34:44 <thingee> hemna: +1
16:34:44 <hemna> not sample config files
16:34:51 <lakhindr_> thingee: I don't talk of the problems in other drivers, sorry.
16:35:18 <lakhindr_> hemna: documentation is for what? sorry did not follow?
16:35:33 <jgriffith> avishay: I have NO problem with people using external config files
16:35:34 <lakhindr_> s/?$/.$/
16:35:56 <hemna> lakhindr_, to describe the more complex configurations of the drivers.
16:36:19 <lakhindr_> hemna: there is already a precedent. Many vendors already use it here!
16:36:26 <avishay> jgriffith: i didn't say i had a problem with it, just asking why not use cinder.conf
16:36:41 <thingee> lakhindr_: and some have spoke about being ok with removing them since we have proper docs now
16:36:43 <xyang_> there's one benefit of this external config file, you don't have to restart cinder-volume.  With cinder.conf, you need to
16:36:44 <hemna> the more complex the configurations are for a driver(s), the better the documentation needs to be.  We don't need sample config files in the source code to help admins.
16:37:21 <lakhindr_> folks this is not about documentation. I agree we can document everything the way it is required. But I want to run tests off a real configuration file.
16:37:27 <thingee> lakhindr_, hemna: and that's why I'm mentioning this. This is not cinder's concern. This is a vendors concern in making sure this conveyed in the proper channels.
16:37:29 <hemna> xyang_, I don't think that's the issue here.   using external configs for a driver is ok...the real issue is, do we allow/want sample config files in cinder source
16:38:00 <lakhindr_> hemna: I say yes. Because we want to test off a sample config.
16:38:27 <hemna> that config should be in the unit test code itself, not in the driver's source tree.
16:38:28 <xyang_> hemna: that's ok. I'm ok to remove it.  I added it there based on some review comments a while back
16:38:31 <thingee> lakhindr_: I've noticed windows storage for example has stuff for their particular tests in cinder.tests.windows
16:38:39 <jgriffith> hemna: +1
16:38:49 <jgriffith> thingee: +1 for you too :)
16:38:53 <thingee> I'm asking hds do the same. Along with moving any simulation code out of the implementation into the test files like the other drivers.
16:39:03 <hemna> thingee, +1
16:39:03 <lakhindr_> Hemna: would you like me to pollute cinder/cinder/tests with a config file?
16:39:16 <thingee> lakhindr_: better than polluting the implementation
16:39:23 <hemna> lakhindr_, pollute the test_hds.py :)
16:39:32 <winston-d> hemna: +1
16:39:36 <thingee> hemna: +1
16:39:49 <lakhindr_> hemna: we have a basic disagreement there. Because I feel value in reading a real config file :-)
16:40:10 <hemna> I don't disagree with reading a "real config file"
16:40:19 <hemna> just put that "config file" as a string in test_hds.py
16:40:29 <lakhindr_> Folks, if this is a big thing, I shall go your way. Just look at my paste bin, and give your comments when we have time. I can post it to some mailing list.
16:40:32 <winston-d> lakhindr_: but you can cover that in tempest tests rather than in unit test
16:40:46 <thingee> lakhindr_: that shouldn't be the focus of your test. Making sure a config file can open *everytime* in a test is not the focus.
16:40:53 <lakhindr_> sorry I don't know the tempest test..
16:41:13 <lakhindr_> thingee: sorry I don't think I agree with what is the 'focus'. That is so subjective..!
16:41:22 <winston-d> lakhindr_: that's integration test framework
16:41:36 <lakhindr_> OK. So then allow me to test things fully!
16:42:00 <lakhindr_> Why is the restriction in testing so tight, please, may I ask? We all have the same goal!
16:42:31 <hemna> we aren't against testing.  we just aren't for polluting the source tree with sample config files.
16:42:43 <jgriffith> Ok, we need to save some time for bswartz and I don't see this really being overly productive
16:42:53 <avishay> yes, this is going around in circles
16:42:59 <hemna> you can accomplish everything you want by just putting that sample config file as a string in your unit test code.
16:43:03 <avishay> hemna: thank you for being the voice of reason :)
16:43:07 <kmartin> lakhindr_: I think the community(along with most of cinder core) and expressed the way they would like you to move forward.
16:43:19 <lakhindr_> OK.
16:43:34 <lakhindr_> Can I still do the simulation then?
16:43:34 <jgriffith> lakhindr_: if you have 3 or 4 folks -1 your patch w/ a recommendation it may be best to at least attempt to cooperate and implement their suggestions
16:43:42 <jgriffith> lakhindr_: but I'll leave that up to you
16:43:52 <jgriffith> #topic shares-service
16:43:56 <jgriffith> bswartz: you're up
16:43:57 <lakhindr_> I will cooperate with you guys of course!
16:43:59 <bswartz> thanks jgriffith
16:44:19 <bswartz> so we have resubmitted the shares service here: https://review.openstack.org/#/c/29821/
16:44:44 <bswartz> for those of you that don't remember the discussion from G3, this is adding support for management of NAS storage to openstack
16:44:56 <kmartin> on to the next easy topic :)
16:45:02 <thingee> :)
16:45:03 <avishay> kmartin: haha
16:45:05 <jgriffith> haha
16:45:19 <hemna> s/openstack/cinder
16:45:23 <hemna> :P
16:45:46 <bswartz> Everyone agrees that management of NAS storage shouldn't be in cinder long term, but in teh short term, creating a new service in cinder is the fastest way to get the community started, and to get the feature into customer's hands
16:45:58 <bswartz> yes hemna
16:46:34 <jgriffith> bswartz: fast != correct
16:46:47 <bswartz> the main things we've done between G3 and now have been to write up some good documentation, and add tests to tempest, and also bring the share service up to parity with many new volume features from grizzly
16:46:50 <jgriffith> bswartz: and I'm concerned about maintenance/support more than anything else
16:47:26 <jgriffith> bswartz: I haven't seen the docs and tempest tests?
16:47:30 <bswartz> NetApp is signing up to maintain and support the share service the community grows large enough
16:47:48 <jgriffith> bswartz: what about your current code?
16:47:53 <bswartz> jgriffith: the temptest tests are are in a gerrit WIP submission -- they can't go in until the service goes in
16:48:08 <bswartz> jgriffith: we also have devstack support coming, but that depends on the service going in as well
16:48:10 <jgriffith> bswartz: sure, but you can share that stuff w/folks ya know
16:48:22 <jgriffith> bswartz: again, why is all of this being done in a silo?
16:48:34 <bswartz> what silo? we're posting everyting we do publicly
16:48:58 <thingee> bswartz, jgriffith: this is true. Really it's going to slow down development on both shared and block in resources. especially if it's not long term (which I'm not going to argue about)
16:49:21 <hemna> If we know that share service needs to live outside of cinder, and you've been working on this for how many releases now?  Lets just make this it's own separate service now.
16:49:33 <bswartz> anyways I've talked with many of you already, and I'm just asking that you review the code, and +1 it if you like it
16:50:22 <bswartz> hemna: work needs to be done on olso before we can effectively split the code -- right now we effectively share a lot of low level cinder stuff
16:50:25 <hemna> bswartz, we have a vested interest here at HP of getting share service in openstack.  But I still don't think it belongs in cinder.
16:50:30 <jgriffith> bswartz: can you provide links to the devstack, tempest and docs you referred to?
16:50:45 <eharney> i think this inside Cinder vs. outside Cinder probably needs some ML discussion outside of just Cinder folks
16:50:46 <rushi_agr> I'll share links soon..
16:50:47 <avishay> to me having NAS in Cinder is almost as strange as Swift in Cinder
16:50:49 <jgriffith> hemna: +1, my company as well
16:50:55 <thingee> bswartz: from last time we spoke for g3, do we have any other vendors chiming in on the api?
16:50:59 <jgriffith> rushi_agr: thanks :)
16:51:00 <eharney> i haven't heard much from other openstack folks on this
16:51:04 <hemna> avishay, +1
16:51:06 <rushi_agr> Hopefully tomorrow
16:51:19 <jgriffith> rushi_agr: oh... so it's not there yet?
16:51:21 <bswartz> tempest: https://review.openstack.org/#/c/26598/
16:51:23 * jgriffith is confused
16:51:28 <jgriffith> bswartz: cool.. thanks
16:51:31 <thingee> avishay: I've been say just put share in swift!
16:51:39 <hemna> lol
16:51:47 <avishay> hahah
16:51:50 <rushi_agr> Its there...wanted to check as its a month old
16:51:51 <bswartz> rushiagr: do you have the wiki link?
16:51:51 <jgriffith> thingee: +1
16:52:13 <avishay> thingee: "here - your problem now!" :)
16:52:15 <jgriffith> bswartz: rushi_agr so just an observation...
16:52:26 <thingee> bswartz: but seriously any other vendors chime in on the api?
16:52:32 <jgriffith> You've got probably well over 10K lines of code associated with all of this
16:52:38 <bswartz> eharney: are you online?
16:52:43 <jgriffith> How much harder would it really be to just create a project?
16:52:51 <bswartz> yes we estimated about 10k of code
16:52:54 <bswartz> 10k lines
16:52:56 <eharney> yes
16:53:10 <rushi_agr> There is a wiki..need to search for it
16:53:27 <notmyname> maybe I missed a joke, but IRC beeps at me when swift is mentioned. is there something we should be doing on the swift side?
16:53:33 <bswartz> I've talked to eharney about support for gluster in the share service
16:53:51 <guitarzan> notmyname: you missed a joke
16:53:56 <avishay> notmyname: no, it's a joke
16:53:59 <thingee> notmyname: run
16:53:59 <bswartz> hopefully eharney will be able to find time to review
16:54:12 <avishay> notmyname: you might end up with 10k lines of code on your doorstep :P
16:54:15 <eharney> yes, i looked at it a bit ago, and will be diving back into the updated code shortly
16:54:23 <bswartz> eharney: thx
16:54:36 <jgriffith> notmyname: you guys are going to imlement share-services in swift :)
16:54:45 <bswartz> anyways, the big complaint about the code during grizzly was that it wasn't ready until G3 and people were nervous
16:55:01 <notmyname> jgriffith: I'll be happy to -2 10k line patches in swift :-)
16:55:02 <hemna> and that it doesn't belong in cinder
16:55:07 <jgriffith> notmyname: :)
16:55:19 <bswartz> we're here now in H1 and we're committed to fixing any issues during havana, and tempest /cinderclient/devstack stuff will come not long after the code is accepted
16:55:19 <avishay> notmyname: lol
16:55:21 <jgriffith> and that it only supported NetApp
16:55:21 <med_> notmyname, as long as you don't +2 in cinder
16:55:35 <jgriffith> med_: HA!!
16:55:53 * notmyname is not sure what a share service is
16:56:02 <jgriffith> bswartz: so if it goes in and bugs get to a threshold and aren't being fixed, and it's not keeping up...
16:56:10 <jgriffith> That means it can be removed without objection?
16:56:13 <med_> notmyname, nfs, smb, etc.
16:56:28 <notmyname> ah
16:56:42 <bswartz> yeah if netapp can't maintain it or build a community to maintain it then it should be trashed, absolutely
16:56:43 <med_> thinks NAS
16:56:47 <hemna> jgriffith, pulling 8k lines of code spread throughout cinder....at the last minute of H3.
16:56:49 <hemna> gives me chills
16:56:54 <bswartz> we're just asking for an opporunity to get started
16:57:30 <bswartz> incubating a whole new project is a LONG process
16:57:37 <jgriffith> bswartz: Just to be clear for the past year and a half there's been an opporunity
16:57:41 <bswartz> We'd like to do what nova-volume did
16:57:50 <jgriffith> bswartz: you would've been through it by now FYI
16:57:56 <hemna> The safest place for share service and the most flexibility for share service and it's core members I believe is in it's own project.
16:58:03 <jgriffith> bswartz: and there's a reason that it's a long process
16:58:16 <jgriffith> bswartz: this short cut is a dangerous deal whether you think so or not
16:58:22 <bswartz> I think the community for shares will largely overlap with the community for block storage
16:58:33 <jgriffith> bswartz: I don't think that's true
16:58:47 <jgriffith> bswartz: I have a difficult time with resources on block as it is
16:58:48 <bswartz> not 100%, but many storage vendors have solutions for both
16:58:57 <avishay> The community may overlap, but I think these two sides to Cinder will influence each other in bad ways
16:59:00 <jgriffith> bswartz: I don't need more vendors adding drivers
16:59:07 <jgriffith> bswartz: I need folks to work on the core project
16:59:39 <eharney> i still think the question of incubating within Cinder vs. starting another project needs to hit the ML for input from some non-Cinder folks
16:59:44 <jgriffith> bswartz: anyhow...  I stil would urge you guys to do this right and create a project
16:59:51 <jgriffith> bswartz: you've already done most of the work
17:00:00 <kmartin> bswartz: say we allow it in cinder for the time being, would it almost be impossible to pull it back out when it becomes it's own service, we're talking 7500 lines of code, where it really belongs in the first place
17:00:10 <jgriffith> eharney: we've tried that and there was very little input from the dev community
17:00:19 <thingee> jgriffith, bswartz: own project and incubated by openstack +1
17:00:28 <hemna> thingee, +1
17:00:28 <jgriffith> kmartin: we did take steps to address that
17:00:47 <eharney> jgriffith: hrm, seems odd, but maybe that's why i haven't heard much from outside
17:00:52 <bswartz> kmartin: disabling the service if we're not happy with it doesn't require changing much
17:00:55 <jgriffith> kmartin: netapp and bswartz inparticular were extremely cooperative in working with me on the design last summer to help with that
17:00:56 <danwent> jgriffith: heads up, i believe there's another meeting starting here very soon
17:01:08 <thingee> bswartz: if it was its own project you could +2 it now
17:01:13 <jgriffith> danwent: thank you sir
17:01:16 <thingee> bswartz: :)
17:01:19 <jgriffith> folks, we're out of time
17:01:25 <jgriffith> #openstack-cinder
17:01:25 <avishay> own project +1
17:01:25 <bswartz> thanks everyone
17:01:30 <jgriffith> we're all there anyway
17:01:37 <kmartin> I was talking about pulling the code out, not disabling it
17:01:37 <jgriffith> #endmeeting