16:01:14 <jgriffith> #startmeeting cinder
16:01:15 <openstack> Meeting started Wed Dec 19 16:01:14 2012 UTC.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:18 <openstack> The meeting name has been set to 'cinder'
16:01:23 <thingee> o/
16:01:27 <eharney> o/
16:01:28 <bswartz> hi
16:01:33 <avishay> hi
16:02:26 <jgriffith> hey .... ok, of course the folks who's BP's I pushed out yesterday aren't here :)
16:02:48 <jgriffith> Let's get started anyway and they can catch up or we can back-track
16:02:54 <jgriffith> #topic G2 status
16:03:09 <jgriffith> We're looking pretty good I think
16:03:32 <jgriffith> I did push out local-volumes, expected_states and the metering BP's
16:03:49 <bswartz> the date is Jan 10th right?
16:04:00 <jgriffith> bswartz: hehe... well as of today yes
16:04:11 <rushiagr> hi, oops, m late
16:04:52 <jgriffith> So that's possibly going to change
16:05:15 <jgriffith> There's some schedule tweaking going on to accomodate when the summit might land
16:05:34 <jgriffith> Most likely it will stay, but ther'es a possibility that it will push out a week
16:06:31 <bswartz> more time is always welcome
16:06:40 <jgriffith> :)
16:07:14 <jgriffith> anyway..
16:07:16 <jgriffith> https://launchpad.net/cinder/+milestone/grizzly-2
16:07:41 <jgriffith> I'm still concerned about volume-backups, anybody have any updates on that one?
16:07:54 <frankm> I can talk about that
16:08:11 <jgriffith> hey... frankm didn't see ya standing there
16:08:41 <frankm> The architecture changes for the port are larger than we expected in terms of volume handling
16:09:09 <frankm> We're working though them, it's slowed us down a little
16:09:39 <jgriffith> so what are your thoughts re G2?
16:09:52 <frankm> But on the plus side the volume backups will fit into the pluggable backend architecture
16:09:59 <jgriffith> and btw do you have anything up on github for folks to start looking at?
16:10:08 <frankm> We're still pushing to hit G2
16:10:54 <frankm> Nothing on githib yet, we should have something up there early in new year
16:10:58 <jgriffith> frankm: hmm... I'm kinda worried
16:11:11 <jgriffith> frankm: only because it's a fairly significant change
16:11:22 <jgriffith> frankm: I'm worried we won't have the review time it deserves
16:11:51 <DuncanT> We're pushing as fast as we can - as soon as we've got a draft to review, we'll put something up
16:12:11 <thingee> frankm: it would be good if you can have it broken up if possible so we can start reviewing some of it.
16:12:12 <jgriffith> DuncanT: frankm Just to be clear, not a knock on your efforts at all
16:12:20 <jgriffith> DuncanT: frankm just trying to plan ahead
16:12:26 <DuncanT> np
16:12:30 <frankm> I understand
16:12:48 <jgriffith> with most folks taking next week off I'm concerned the patch lands a day before lockdown :)
16:13:31 <jgriffith> Remember, release is the 10'th but we freeze a few days before that
16:15:15 <DuncanT> We'll push as hard as we can to get something in as early as possible
16:15:35 <jgriffith> Ok we'll leave it for now and I"ll touch base with you after Christmas :)
16:15:56 <jgriffith> Maybe we'll get an extra week, should know the answer to that later this week
16:16:17 <bswartz> If G2 slips, then would G3 automatically slip too?
16:17:11 <jgriffith> bswartz: yeah
16:17:28 <jgriffith> So the background is that we're talking about slipping G3 to aline closer to the summit date
16:17:37 <jgriffith> as a result everything would slide
16:17:50 <jgriffith> anyway, I'll let everyone know if that happens
16:18:11 <jgriffith> and now I'm off my conf call so you all have my full undivided attention :)
16:18:22 <jgriffith> back to remaining G2 items...
16:18:39 <jgriffith> I think I've touched base with everyone
16:18:56 <jgriffith> Anybody concerened they're not going to hit next week?
16:19:12 <jgriffith> Or first week of January?
16:19:25 <jgriffith> Or any surprises that aren't on this list that should be?
16:19:45 <xyang_> Hi John.  This is Xing.  How about the code review for EMC Volume Driver?  Are you going to review it?
16:20:00 <jgriffith> xyang_: yep
16:20:23 <jgriffith> Ok... if nobody wants to talk about G2
16:20:42 <jgriffith> the only thing I'll add is as always we need reviewers
16:20:57 <jgriffith> If you're on core you should be looking at this at least once a day IMO
16:21:00 <bswartz> how much is ready for review already?
16:21:07 <jgriffith> bswartz: ?
16:21:12 <xyang_> Sorry I missed the beginnig of the meeting.  When will be G2?
16:21:28 <bswartz> I mean how much more is coming relative to what's done now?
16:21:32 <jgriffith> xyang_: Jan 10, but that last week is bug fixes only
16:21:39 <bswartz> review-wise
16:21:41 <jgriffith> bswartz: a good bit :)
16:21:48 <jgriffith> https://launchpad.net/cinder/+milestone/grizzly-2
16:22:01 <jgriffith> bswartz: You can see the status of the targetted items there
16:22:18 <bswartz> I'll take a look at the "needs code review" stuff
16:22:18 <jgriffith> but also keep in mind there is work going on outside of targetted
16:22:37 <jgriffith> it's best if folks can just jump on gerrit and search for open reviews in cinder and cinderclient
16:22:51 <jgriffith> anyway...
16:22:59 <rushiagr> i started putting in couple of hours each day for code review, from today
16:23:10 <jgriffith> #topic external PYPI includes
16:23:26 <jgriffith> So the HP 3Par driver brings up an interesting new twist
16:23:37 <jgriffith> they have an external lib published to PYPI
16:24:11 <jgriffith> This raises the question of packaging/adding it to the cinder project requires
16:24:18 <bswartz> external for licensing reasons?
16:24:23 <galthaus> So, the question is how to handle dynamic dependencies?
16:24:32 <avishay> jgriffith: I commented on that in my code review of the driver...seems odd
16:24:35 <jgriffith> bswartz: thank goodness NO, otherwise it wouldn't even be a question IMO
16:24:39 <kmartin> hemna is not on but I should be able to answer any questions
16:24:57 <jgriffith> So the idea is they have it for other uses so don't want to maintain in two places
16:25:07 <bswartz> okay
16:25:16 <jgriffith> It's valid IMO, however I'm not crazy about it
16:25:53 <avishay> Is there any way to keep the model but not require every user to install the client, regardless of what back-end they use?
16:25:59 <bswartz> yeah it seems like you can keep the seperation between cinder and non-cinder things at an API level and not having to do funky code imports
16:26:28 <jgriffith> so the good thing is it's licensed under Apache
16:26:42 <jgriffith> I'm leaning towards implement it in the driver like the rest of us...
16:26:44 <jgriffith> Or...
16:27:01 <jgriffith> You can include it to get sucked in for unit tests but not in the release packaging
16:27:38 <galthaus> ah - so the problem is more with the unit tests than the actual delivery of the driver.?
16:27:43 <avishay> Unit tests use the fake driver - why is the real client needed?
16:27:52 <jgriffith> :)
16:28:10 <jgriffith> So this brings up all sorts of issues so let me just propose this:
16:28:24 <jgriffith> My personal thought is I do NOT want to go this route
16:28:38 <jgriffith> while it makes sense for HP and their maintenance it's bad for ours
16:28:51 <jgriffith> we technically should be reviewing their PYPI lib
16:29:30 <jgriffith> I don't see why the existing httlib, json and  other tools can't be used in OpenStack
16:30:27 <jgriffith> for those that are intersted and haven't seen it:  http://pypi.python.org/pypi/hp3parclient
16:30:42 <galthaus> Where does there lib hook in?  I haven't look at the pull request.
16:30:58 <galthaus> Does it use a driver to wrap calls to hp3parclient?
16:31:04 <jgriffith> https://review.openstack.org/#/c/18351/
16:32:15 <jgriffith> walter you around?
16:32:33 <avishay> galthaus: the impression i got is that things related to the controller are in the separate package, and things related to OpenStack are in the driver
16:32:38 <kmartin> jgriffith: no he's not on
16:32:44 <jgriffith> kmartin: bummer
16:33:00 <galthaus> avishay: It appears that way.
16:33:16 <jgriffith> avishay: galthaus yeah... sorry
16:33:47 <jgriffith> avishay: galthaus what I haven't quite figured out is the need for it in unit tests
16:34:13 <avishay> I also didn't really understand why there was ~100 LOC implementing SSH functions when there are available functions
16:34:14 <aabes> seems that the client throws typed exceptions
16:34:28 <aabes> defined in the hp3par client module
16:34:32 <jgriffith> aabes: yeah, but that's the only thing I can find
16:35:19 <aabes> seems that they host the code on github... http://packages.python.org/hp3parclient/installation.html
16:35:31 <aabes> can a similar approach to the openstack-common address the issues
16:35:45 <galthaus> yep - stubs for those and draw the line going forward that You need to provide stub libraries for external non-common dependencies.
16:36:01 <galthaus> I'm not happy with that statement either, btw.
16:36:21 <kmartin> avishay: the problem is the driver is ahead of the 3par release cycle, so the need to fall back to SSH
16:37:14 <avishay> kmartin: i didn't do a thorough review, but couldn't they have used available SSH functions?
16:37:23 <jgriffith> avishay: +1
16:37:36 <jgriffith> So here's the main question IMO
16:37:59 <jgriffith> Do we want to set a precedent of just using your own published external libs to do drivers in Openstack/cinder?
16:38:12 <kmartin> we could but due to the limited ssh connection on the 3par array we wanted to the REST route
16:38:45 <winston-d> sorry, i'm late
16:38:51 <aabes> jgriffith: what about binary distributions?
16:39:14 <jgriffith> aabes: yeah so that's the next problem right
16:39:20 <bswartz> jgriffith: I can see both advantages and disadvantages, I'm not sure I have a strong opinion on that one
16:39:48 <aabes> or otherwise non OS code... vendors might chose not to expose internal efficient protocols.. mostly so they control the UX and support
16:39:49 <jgriffith> bswartz: the disadvantage is when there's a bug reported against Cinder and we have to try and fix it
16:40:12 <jgriffith> bswartz: and the bug is in their PYPI lib
16:40:45 <jgriffith> bswartz: It's not that we don't deal with external tool chains already but we use them in a global manner
16:40:54 <aabes> jgriffith: does that point towards coverage of unit tests?
16:40:57 <jgriffith> using them for a single driver in a project seems off to me
16:41:09 <jgriffith> aabes: sure, in theory :)
16:41:25 <bswartz> if the bug is only triggered when the 3par driver is active, I don't see how any would have a problem with it who wasn't also empowered to fix the bug where it needs to be fixed
16:41:36 <bswartz> anyone* would have a problem
16:42:11 <jgriffith> bswartz: My point is I don't want to have to muck around with their client to triage or fix a bug that gets reported in Cinder
16:42:21 <aabes> there's still the test-requires issue...
16:42:42 <jgriffith> aabes: yup
16:42:44 <bswartz> yeah the unit tests seems like a bigger issue than the bugs issue
16:42:54 <aabes> if there's a test-fake-requires or somesuch, that allows you to test with fakes
16:42:56 <jgriffith> bswartz: agree
16:43:06 <galthaus> jgriffith: But you have a worse problem in some regards if you make them include code that is specific to their stuff anyway.
16:43:11 <aabes> or maybe the otherway around - test-<vendor>-requires
16:43:21 <jgriffith> galthaus: except it's in their driver :)
16:43:30 <galthaus> This is in their library
16:43:40 <jgriffith> galthaus: we have access to the repo, single bug system, single review process etc
16:44:05 <aabes> jgriffith: you'd still need a 3par box to be able to test it ;)
16:44:19 <jgriffith> aabes: and there's the big problem with all of our drivers :)
16:44:50 <galthaus> Yeah - I guess I don't see the distinction from a driver with specialized code and a driver that calls a library with specialized code.
16:45:03 <bswartz> yeah that argues for not worrying about the bug thing -- a bug that is driver specific is not really fixable by people other than the vendor anyways
16:45:04 <jgriffith> alright, well I'm not getting a clear picture on how people feel about this topic
16:45:08 <aabes> imho, vendors will be highly motivated to give their users good UX and quick resolution to problems, as long as the finger can be pointed squarely at them
16:45:14 <avishay> but if i make a change to cinder that requires minor changes to all drivers, i can do that, until now
16:45:47 <jgriffith> galthaus: I guess my point was that if it's a lib or a driver doesn't matter but my point was it might be best if it resided in Openstack/Cinder
16:45:48 <bswartz> I don't think we need to worry too much about driver-specific bugs -- they only affect a subset of users, and those user presumably have contacts directly to their vendors
16:45:51 <galthaus> avishay: can you?  I'm not sure you can safely do it in ither case.
16:46:12 <jgriffith> bswartz: disagree... have you seen the bugs being logged against NetApp :)
16:46:22 <bswartz> yes, I was going to mention those
16:46:36 <jgriffith> bswartz: theyre' logging them in Luanchpad against Cinder, not their NetApp support contacts
16:46:37 <avishay> my feeling is that i don't really care, but i'd rather not have to install this library if i don't use it
16:46:37 <bswartz> I don't expect cinder-core people to fix our bugs
16:46:46 <DuncanT> avishay: What's the difference between an ssh call that does unknowable magic and a local python call that does unknowable magic? Either way I can't change it without knowiing the semantics
16:46:46 <bswartz> we are fixing our own bugs
16:46:51 <galthaus> jgriffith: yeah.  There is a nicety to having it in your space.
16:47:25 <jgriffith> Ok... so no clear outcome here it seems
16:47:29 <jgriffith> How about this....
16:47:30 <galthaus> avishay: I think that is the underlying question.  Can we design/tweak the system to enable custom libraries, but validate taht the cinder code works.
16:47:33 <kmartin> avishay: the driver is still in cinder,  just the python wrapper client that lives in the pypi, and the driver has unit test that also resides in cinder
16:47:39 <jgriffith> Folks that are so inclined take a look at the review
16:47:57 <jgriffith> If there are things that the unit tests can/should be doing without the client then suggest it
16:48:08 <jgriffith> If we need to add it to test-requires, cool, we'll do so
16:48:14 <jgriffith> For end users....
16:48:43 <kmartin> Yep, please comment on the review and Walt will be in later today to respond :)
16:48:44 <jgriffith> We don't try to get Cannonical and others to package it we jsut document it in the drivers section that the end user needs to install the lib
16:48:53 <aabes> hmm... seems that some of the netapp bugs (the 2 i looked at) have to do with cinder->driver expectations....
16:49:19 <jgriffith> aabes: and good lead in...
16:49:25 <aabes> (have a plan to get a readme in lace, but other priorities)
16:49:25 <jgriffith> #topic driver bugs
16:49:35 <jgriffith> So this is NOT NetApp specific
16:49:35 * bswartz hides
16:49:40 <jgriffith> this is general
16:50:05 <jgriffith> so part of having a driver accepted in to Cinder and OpenStack is it's supported and it's part of OpenStack
16:50:17 <jgriffith> That means that we ALL have to support it
16:50:28 <jgriffith> we all have to contribute to bug fixes etc
16:50:38 <bswartz> jgriffith: what if a bug is only reproducible with real hardware?
16:50:46 <jgriffith> While there are cases that this may not be practical due to hardware that's not always the case
16:51:04 <jgriffith> bswartz: agreed, there are cases where that's going to happend
16:51:06 <jgriffith> happend
16:51:12 <jgriffith> AHHHH... keyboard
16:51:23 * jgriffith is removing the d key
16:51:53 <jgriffith> but really,if we're not supporting what we put in then what's the point in integrating the driver?
16:52:16 <jgriffith> If you want to go that route just provide your customers with a patch or a driver yourself and leave the rest of us out of it :)
16:52:27 <bswartz> I thought the point was to make it easy for the linux distros to redistribute all the drivers
16:52:42 <jgriffith> bswartz: the point is that it's a supported OpenStack componenet
16:52:45 <aabes> and users to consume it ;)
16:52:45 <jgriffith> component
16:52:52 * jgriffith can't type this morning
16:53:30 <bswartz> I don't think it's unreasonable to take the stance that Cinder distributes vendor-specific drivers, but does not support them
16:53:36 <jgriffith> really, if all OpenStack is to folks is a packaging method then I'm sure wasting an awful lot of my time
16:53:58 <bswartz> if supporting them is really what we want to do, then I agree we need something better than what we have
16:53:59 <jgriffith> bswartz: haha that should go over really well
16:54:31 <jgriffith> bswartz: Ok, well I'll just start marking any bug that comes in and somebody is using a third party driver as invalid
16:54:40 <jgriffith> I'll say, "not supported, just packaged"
16:54:42 <aabes> looking at ceph... cinder provides path to innovative integration of the pieces of openstack...
16:55:04 <aabes> yes.. you could in theory go and fix bugs in their code, but do you have a handy cluster of scale to test on?
16:55:10 <bswartz> jgriffith: we track bugs internally -- the reason that there are also bugs filed against cinder is so we have something to reference when the fix goes in
16:55:29 <jgriffith> alright, I think I'm wasting my breath
16:55:34 <jgriffith> but I'll just say...
16:55:52 <jgriffith> We still HAVE to triage every bug and make sure the problem is not in the Cinder infrastructure
16:56:27 <aabes> this one feels like an enhance,net request for the infra: https://bugs.launchpad.net/cinder/+bug/1091480
16:56:29 <uvirtbot> Launchpad bug 1091480 in cinder "NetApp: Errors if requests are too close together" [Undecided,New]
16:56:37 <jgriffith> but what you're saying is that if we do that and get to the point where it's in somebody's driver then leave it alone until somebody from NetApp, SolidFire or wherever comes in and fixes it?
16:56:43 <aabes> a backoff mechanism, that might be applicable to many drivers
16:56:55 <jgriffith> aabes: Yeah, and the answer is NO
16:57:01 <aabes> :(
16:57:19 <jgriffith> Until it's evident that a backoff mechanism is needed by all the other drivers
16:57:22 <jgriffith> IMO
16:57:28 <aabes> that sounds fair.
16:57:33 <bswartz> okay so I need to grab netapp specific bugs and assign them to myself or rushi, so they don't distract you guys
16:57:57 <bswartz> sorry I didn't do that
16:58:16 <jgriffith> bswartz: No, that's not really my point
16:58:27 <jgriffith> bswartz: I don't think there's anything wrong or bad about anything right now
16:58:39 <jgriffith> bswartz: I was just wanting to clarify some expectations
16:58:52 <jgriffith> bswartz: but it seems I'm in the minority on this one as well
16:59:14 <jgriffith> Folks seem to agree that OpenStack/Cinder is just a packaging/distribution mechanism for the vendors
16:59:21 <jgriffith> so much for OpenSource
16:59:46 * jgriffith walks away depressed
16:59:54 <bswartz> I think we're still getting benefits from open source here -- in case you didn't notice, one of our users actually fixed a bug he found in the netapp driver
17:00:20 <jgriffith> bswartz: ahh... and there's my point
17:00:29 * winston-d agrees with jgriffith on this one
17:01:03 <jgriffith> bswartz: So the reason we review drivers and such is becuase we are expecting to offer at least some level of support
17:01:42 <jgriffith> anyway... like I said, this applies to all drivers IMO
17:01:57 <jgriffith> this is NOT a NetApp related rant on my part or anything else
17:02:13 <jgriffith> Meanwhile... it's also not very constructive so moving on
17:02:15 <bswartz> okay -- so is the concern that our current model is incompatible with the plan for 3par wants to do?
17:03:01 <bswartz> I like the idea of drivers being supported to the extent possible by the core team, as long as we understand there are limits to that support where real hardware is required
17:03:23 <avishay> over time limit, gotta go - bye all
17:03:31 <jgriffith> bswartz: indeed
17:03:41 <jgriffith> bswartz: there are limits for sure
17:03:50 <jgriffith> bswartz: but we should make an effort
17:04:23 <jgriffith> alright... we're about out of time
17:04:31 <jgriffith> #topic open discussion
17:04:31 <hemna> ok what did I miss?
17:04:51 <winston-d> hemna: you missed almost everything. :)
17:05:05 <jgriffith> haha
17:05:12 <aabes> ;)
17:05:20 <jgriffith> hemna: we can talk offline
17:05:34 <eharney> jgriffith: rtslib has been put into pypi now, so i'm going to go look at that for the LIO changes
17:05:51 <jgriffith> eharney: :)
17:05:59 <aabes> are we missing a possible benefit here - perusing through the 3par lib.. it mostly does very plain vanila things.
17:06:01 <jgriffith> eharney: when did it land?
17:06:15 <jgriffith> aabes: yeah, that's the beauty of it
17:06:20 <eharney> jgriffith: yesterday evening
17:06:25 <jgriffith> eharney: nice!
17:06:38 <hemna> heh ok
17:06:39 <jgriffith> So how about this:
17:06:43 <hemna> I just got in the office
17:06:53 <aabes> define a few exceptions, and a few very basic methods. most seem generally applicable to cinder...
17:06:54 <jgriffith> add the external lib to the test-requires only
17:07:10 <jgriffith> for customers that want to use it document it as a requirement
17:07:23 <jgriffith> in your driver add a check-setup function that verifies it's there
17:07:56 <jgriffith> In the case of the HP client this is works becuase it's Apached licensed so there's no conflict
17:08:02 <hemna> and how do you get the check-setup to be called prior to the import ?
17:08:20 <jgriffith> hemna: You could do an __init__
17:09:01 <jgriffith> hemna: I think it would work to do something like:  /drivers/hp/__init__.py, 3par_driver.py
17:09:23 <jgriffith> hemna: There are also ways to wrap the import
17:09:30 <hemna> ok
17:09:42 <jgriffith> hemna: in fact IIRC there's a function in utils to do that
17:09:44 <jgriffith> anyway
17:09:56 <jgriffith> anybody else haveinput or care?
17:10:01 <jgriffith> :)
17:10:30 <jgriffith> If you think I'm worrying about nothing please say so
17:10:41 <hemna> so I presume the major point of the discussion was around not adding the 3rd party library to pip-requires, where a particular driver is the only code that needs it?
17:10:48 <DuncanT> I'm going to have to re-read the whole debate to be able to form a real opinion TBH
17:11:02 <DuncanT> But I suspect your worries are not unreasonable
17:11:05 <jgriffith> DuncanT: Yeah, and there's some filtering of the other topics there
17:11:13 <jgriffith> hemna: Yes, that's what I was thinking
17:11:20 <hemna> ok
17:11:43 <jgriffith> hemna: It doesn't seem unreasonable to me and maybe we'll change it later
17:11:43 <DuncanT> Shall we give people a chance to read the code & the comments made, digest and comment again next meeting?
17:11:50 <hemna> I guess it would be a moot point if there was a built in mechanism that allowed for deps for components to be pulled only when they are used.
17:11:53 <jgriffith> DuncanT: indeed, very good point
17:11:54 <hemna> but that's probably asking too much
17:12:18 <jgriffith> #proposal Folks check out the 3par review and lib and form an opinion on test-requires and pip-requires
17:12:42 <hemna> I don't think it's unreasonable to not install it by default, since in this particular case, only people that are going to use the driver need it.
17:12:53 <zykes-> Soa! any FC status ? :)
17:12:57 <zykes-> just dropping in !
17:13:00 <winston-d> will do
17:13:14 <jgriffith> kmartin: ^^
17:13:25 * zykes- guesses for hp legal :p
17:13:35 <jgriffith> zykes-: I believe it's cleared
17:13:36 <kmartin> zykes-: Cleared the HP legal hurdle, all clear to submit
17:13:37 <hemna> jgriffith, fwiw in the review I don't think I added the pip-requires changes, but only the test-requires
17:13:47 <jgriffith> hemna: :)
17:13:54 <jgriffith> #topic next weeks meeting
17:14:08 <jgriffith> Planning to skip, anybody have an objection?
17:14:08 <zykes-> kmartin: got a few after the meeting ?
17:14:33 <jgriffith> Or course anybody is welcome to chair in my absence
17:14:51 <kmartin> zykes-: sure until another meeting I have to attend at 9:30
17:15:25 <jgriffith> Ok... no meeting next week unless somebody voices an objection between now and then
17:15:38 <kmartin> jgriffith: HP is shut down next week, so we will not be in the office
17:15:55 * jgriffith misses shut-downs
17:16:10 <jgriffith> alright... Have a great Christmas everyone
17:16:20 <kmartin> jgriffith: you too
17:16:24 <jgriffith> or other Holiday that you may choose to celebrate :)
17:16:28 <jgriffith> #endmeeting