16:00:00 <thingee> #startmeeting Cinder
16:00:00 <openstack> Meeting started Wed Oct 15 16:00:00 2014 UTC and is due to finish in 60 minutes.  The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:01 <hemna> how d
16:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:04 <openstack> The meeting name has been set to 'cinder'
16:00:06 <cknight> Hi
16:00:10 <thingee> Hi everyone
16:00:13 <kmartin> o/
16:00:24 <jungleboyj> o?
16:00:26 <hemna> I don't think we have enough on the agenda
16:00:27 <patrickeast> hey
16:00:27 <hemna> :P
16:00:28 <jungleboyj> o/
16:00:29 <jungleboyj> I mean
16:00:35 <xyang1> hi
16:00:38 <DuncanT-1> hi
16:00:40 <eharney> hi
16:00:41 <thangp> o/
16:00:43 <thingee> We have a lot to go over, so lets get to it!
16:00:45 <smcginni1> o/
16:00:53 <thingee> #topic OSLO liason
16:01:08 <thingee> oh yes, the agenda for today https://wiki.openstack.org/wiki/CinderMeetings
16:01:11 <jgriffith> DuncanT-1: isn't that you ?
16:01:21 <glenng> Hi all!
16:01:24 <jungleboyj> jgriffith: I was wondering that too.
16:01:34 <thingee> so someone else can offer on a per release
16:01:38 <thingee> this will be for kilo
16:01:39 <DuncanT-1> jgriffith: Timezone changes are going to make that impractical
16:01:42 <thingee> sign up is at https://wiki.openstack.org/wiki/CrossProjectLiaisons
16:01:52 <DuncanT-1> jgriffith: So I'm stepping down
16:01:57 <jgriffith> DuncanT-1: got it
16:02:05 <thingee> I'm still looking for someone to facilitate this.
16:02:19 <winston-d> DuncanT-1: you are moving somewhere else?
16:02:29 <DuncanT-1> winston-d: Israel
16:03:01 <winston-d> DuncanT-1: wow, nice.
16:03:05 <jungleboyj> If no one else is interested I can take a look at this.
16:03:08 <hemna> considering that I don't plan on putting brick into OSLO, I'm not sure I'm the right person for the oslo liason :P
16:03:16 <jungleboyj> DuncanT-: Is it just making sure we keep things in sync?
16:03:18 <jgriffith> jungleboyj: You'd be a good fit IMHO
16:03:25 <thingee> jgriffith: +1
16:03:27 <jgriffith> jungleboyj: you've been doing a lot of this sort of work anyway
16:03:41 <jgriffith> jungleboyj: with the i8n and gettext stuff
16:03:43 <thingee> I've been actually waiting for jungleboyj to step up to it. :)
16:03:44 <jungleboyj> jgriffith: I knew I would regret saying that.  ;-)
16:03:51 <hemna> :)
16:03:57 <DuncanT-1> jungleboyj: Keeping things in sync, working through graduations (see the bug I filed today), generally talking to the oslo guys about cinder problems
16:03:57 <jgriffith> jungleboyj: thingee how about jungleboyj considers it
16:04:10 <jungleboyj> Ok ok.  I am on it. :-p
16:04:10 <jgriffith> if he's not sure I can maybe take a look at it
16:04:15 <jgriffith> jungleboyj: sweet!
16:04:22 * jgriffith dodges a bullet :)
16:04:34 <jungleboyj> I was going to look into it more but have been out since last Friday.
16:04:38 <jungleboyj> I will go sign myself up.
16:04:43 <thingee> #agreed jungleboyj will be the OSLO liaison from Cinder for Kilo
16:04:43 <kmartin> next topic before jungleboyj changings his mind
16:04:49 <thingee> jungleboyj: thank you :)
16:04:53 <jgriffith> jungleboyj: honestly it's not a huge undertaking and working with dhellmann and co is rather nice
16:05:05 <jungleboyj> jgriffith: Agreed.
16:05:14 <thingee> #topic thirdparty CI voting permissions
16:05:24 <hemna> 1 beer for jungleboyj
16:05:26 <thingee> #link https://etherpad.openstack.org/p/cinder-meeting-20141008
16:05:29 <jungleboyj> Plus the guys I work with a lot is always active in Oslo, so it shouldn't be a big deal.
16:05:32 <thingee> hemna: +1
16:05:35 <jungleboyj> hemna: Thanks!
16:05:51 <thingee> so not too many people were involved with the discussion here.
16:06:08 <thingee> I'm also in agreement with jgriffith that it doesn't make much sense at this point.
16:06:18 <thingee> I would like to see CI's become a common thing before I worry about this
16:06:24 <hemna> thingee, +1
16:06:37 <thingee> Honestly I would like to help vendors on this front and focus on getting people there, before we worry about this
16:06:46 <thingee> and asselin_ has been a big help with helping me :)
16:06:58 <jungleboyj> thingee: +1
16:07:05 <bswartz> .o/
16:07:30 * DuncanT-1 can't see a downside to letting those who think they're ready vote, but meh, it isn't that important, I can script around it
16:07:58 <winston-d> is vendor CI supposed to vote for every commit?
16:07:58 <thingee> #idea punt ci voting permissions until we can help vendors with setting up their CI systems.
16:07:59 <patrickeast> so if that is the decision can we update https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver#Third_Party_CI_Requirement_Policy with our current policy?
16:08:04 <thingee> winston-d: yes
16:08:09 <thingee> patrickeast: yes
16:08:18 <jgriffith> thingee: so I guess my take was different here....
16:08:33 <jgriffith> thingee: my take was "if you think you are ready and want to do it it's on you"
16:08:43 <winston-d> for example, I didn't see SolidFire CI's +-1 on some patch set for jgriffith's last SF driver change.
16:08:47 <jgriffith> thingee: but that the Cinder team shouldn't be making it a requirement (yet)
16:08:53 <jgriffith> or focusing a ton of time/effort on it
16:09:11 <jgriffith> winston-d: yeah... I need to adjust my system after that goes through :)
16:09:22 <thingee> honestly I would like those people that are ready to help others than focus on meeting a non-requirement.
16:09:31 <jgriffith> winston-d: I only vote on Jenkins +2 and I have an issue with network dropping in my lab
16:09:47 <glenng> jgriffith: Question then is whether it is a blocking vote. Bad CI can block a lot of work.
16:09:50 <jgriffith> so I don't report failures on that particular case.  that patch should allow me to change that
16:09:59 <jgriffith> glenng: never blocking IMO
16:10:00 <DuncanT-1> glenng: No, it is never a blocking vote
16:10:10 <glenng> *feels better then*
16:10:23 <jgriffith> thingee: +1 I think your points are good ones
16:10:42 <thingee> #action thingee to update wiki on this not being a requirement
16:11:20 <thingee> #agreed to punt until we can have better documentation to help vendors getting their CI's setup
16:11:53 <thingee> #action thingee to help start documentation on getting a CI setup for Cinder as he is learning
16:12:04 <thingee> anything else?
16:12:19 <patrickeast> sounds good to me
16:12:24 <jungleboyj> +1
16:12:44 <thingee> thank you everyone for the help and discussion on this from here https://etherpad.openstack.org/p/cinder-meeting-20141008
16:12:51 <thingee> #topic state machine
16:13:02 <thingee> #link https://etherpad.openstack.org/p/juno-cinder-state-and-workflow-management
16:13:19 <thingee> that's the previous discussions
16:13:30 <thingee> and the approved spec for juno
16:13:33 <thingee> #link https://github.com/openstack/cinder-specs/blob/master/specs/juno/create-states.rst
16:13:51 <thingee> harlowja_away and DuncanT-1 listed on this one
16:14:08 <thingee> There are a couple of outstanding patches:
16:14:11 <hemna> so how does this work relate to the volume object state stuff that was discussed in the mid-summit meetup ?
16:14:12 <thingee> #link https://review.openstack.org/#/c/110434/17
16:14:18 <thingee> #link https://review.openstack.org/#/c/124205/
16:14:19 <flip214> thingee: why not use SELECT FOR UPDATE locks in the database instead of a DLM?
16:14:30 <DuncanT-1> https://review.openstack.org/#/c/110434 is pretty much unrelated
16:14:45 <hemna> DuncanT-1, ok that's what I thought.
16:14:52 <DuncanT-1> flip214: Because you can't hold a select lock across an RPC
16:15:18 <DuncanT-1> https://review.openstack.org/#/c/124205/ is starting to head in the right direction
16:15:28 <jgriffith> thingee: harlowja_away so I was good reading the rst doc
16:15:42 <DuncanT-1> The states aren't necessarily the right ones yet, but heading in the right direction
16:15:42 <jgriffith> thingee: harlowja_away and good with https://review.openstack.org/#/c/110434
16:15:59 <jgriffith> thingee: harlowja_away but then I threw up when I looked at the follow ups that were added
16:16:01 <thingee> hemna, DuncanT-1: sorry have them both listed cause there is a dependency link
16:16:14 <flip214> DuncanT-1: and that is needed? I thought that with python green threads blocking the origin thread would hold it via the DB handle?
16:16:30 <DuncanT-1> flip214: RPCs in cinder are mostly none-blocking
16:16:51 <jgriffith> thingee: harlowja_away DuncanT-1 the other proposal we talked about at the mid-cycle meetup;
16:16:54 <asselin_> hi
16:17:00 <flip214> hrmpf
16:17:03 <jgriffith> was to go to an object model for the volume reference
16:17:16 <jgriffith> IMO that in an of itself would be a great start/improvement
16:17:29 <hemna> jgriffith, +1
16:17:35 <DuncanT-1> jgriffith: I am leaning that way for the rolling upgrade stuff
16:17:51 <hemna> that's kinda the confusion I have here.  is how the 2 efforts relate to each other if at all
16:17:51 <jgriffith> DuncanT-1: which way?  The "object" model?
16:17:55 <DuncanT-1> jgriffith: Not convinced it makes a huge difference for state machine
16:18:01 <thingee> jgriffith: are those thoughts documented in the followup review?
16:18:03 <DuncanT-1> jgriffith: Then object model, yeah
16:18:22 <thingee> vilobh and co have been quick on taking care of concerns
16:18:28 <jgriffith> thingee: nope, I've been focused on this little thing called Juno
16:18:30 <rushiagr> o/
16:18:55 <jgriffith> which FYI we haven't finished yet
16:20:02 <thingee> ok, would someone mind raising the concerns, or just spend time explaining to me and I can document them so we can continue progress on this?
16:20:17 <jgriffith> thingee: sure... I'll add a comment to the reivew
16:20:19 <jgriffith> review
16:20:33 <DuncanT-1> thingee: My first concern is that the db to hold microstate won't scale
16:21:00 <DuncanT-1> thingee: So an extra layer of abstraction would really help to develop a scalable alternative in parallel
16:21:11 <hemna> DuncanT-1, and if the microstates aren't persisted somewhere, then we can't really safely shutdown cinder
16:21:46 <thingee> DuncanT-1: ok, lets talk after the meeting. This is better than what I was hearing from people on these patches last week :)
16:22:00 <thingee> I wanted to at least know we're going in somewhat of a right direction that can be improved
16:22:01 <jgriffith> thingee: done
16:22:20 <DuncanT-1> thingee: Unfortunately it'll have to be tomorrow, got to run after the meeting
16:22:38 <thingee> #action jgriffith to raise concerns in patch that were mentioned in midcycle meetup
16:22:50 <thingee> DuncanT-1: sure
16:22:54 <jgriffith> as I said ^^ done :)
16:23:11 <thingee> #agreed patches are going somewhat in right approach and can be improved.
16:23:26 <thingee> #topic rolling upgrades
16:23:31 <thingee> DuncanT-1: you're up
16:23:35 <DuncanT-1> Ok
16:23:36 <hemna> jgriffith, good review notes.   nice
16:23:49 <DuncanT-1> So I've still not posted specs, which is poor of me
16:23:52 <jgriffith> hemna: why thank ya sir
16:24:16 <hemna> DuncanT-1, do we have a cinder-specs yet for this ?
16:24:28 <DuncanT-1> The first part is RPC version clamping - easy to add, should have code up at the same time as the spe
16:24:30 <DuncanT-1> c
16:24:45 <DuncanT-1> hemna: I'll post up something later - it is rough but should do for discussion
16:24:51 <hemna> awesome
16:25:04 <DuncanT-1> RPC version clamping makes everybody's life harder in future though
16:25:07 <jgriffith> DuncanT-1: personally I'd love to see your plan/spec before code :)
16:25:09 <jgriffith> just sayin
16:25:30 <jgriffith> and what "version clamping" means in your context
16:25:35 <thingee> DuncanT-1: I agree with jgriffith.. you'll get frustrated if you don't have an agreed approach to reference later.
16:25:37 <DuncanT-1> jgriffith: The code is only just enough to clearly illustrate the idea, which I was finding really hard in the spec
16:25:46 <jgriffith> DuncanT-1: fair enough
16:26:07 <DuncanT-1> The code should be cleansed with fire before being rewritten for actual merge
16:26:07 <jgriffith> DuncanT-1: I'm just leary because remember we did RPC versioning saying "oh... now we can do rolling upgrades"
16:26:13 <jgriffith> that wasn't quite accurate
16:26:24 <jgriffith> I'd like a better definition of the use case
16:26:30 <jgriffith> or problem we're solving exactly
16:26:32 <DuncanT-1> jgriffith: Yeah, sadly we don't handle what happens when one side can't do the new version yet
16:26:44 <jgriffith> if it's wheels on a moving bus vs transmission and engine
16:26:54 <hemna> round and round....
16:26:55 <DuncanT-1> jgriffith: I'll post something rough and ready tonight or tomorrow
16:27:05 <jgriffith> DuncanT-1: sounds great to me
16:27:19 <DuncanT-1> My fault for letting it slide.... stupid LVM bugs
16:27:32 <thingee> DuncanT-1: posted code or spec??
16:27:50 <bswartz> the code is the spec!
16:27:59 <thingee> #action DuncanT-1 to have rough code posted tonight or tomorrow
16:28:16 <thingee> DuncanT-1: anything else?
16:28:25 <DuncanT-1> thingee: I'll post both
16:28:37 <thingee> #topic Agree on NFS sec patch approach
16:28:40 <DuncanT-1> thingee: That's it for now... db still not covered, but one thing at a time
16:28:44 <thingee> #link https://review.openstack.org/#/c/107693/
16:29:07 <thingee> glenng: you're up
16:29:25 <glenng> I have added comments to recite the Core consensus. Please take a moment to read and comfirm for next patch.
16:29:54 <glenng> There are 3 primary points that I belive that the core came to an agreement on…
16:30:20 <eharney> did everyone actually agree on whether we should do the check in the manager where it isn't needed by many drivers, vs. a db call in the driver?
16:30:38 <jgriffith> eharney: :)
16:30:45 <jgriffith> eharney: I'm going to yield on this one I think
16:30:53 <glenng> eharney: That was what I got from it. Almost everyone did not want the driver looking in the DB.
16:30:55 <jgriffith> eharney: your point about the init timing is fair
16:31:15 <thingee> I still think we're doing workarounds a requirement that's not even a problem in this case.
16:31:20 <jgriffith> eharney: I still think it's doable but I don't want to block this or continue making waves
16:31:24 <eharney> i'm basically where thingee is on that
16:31:35 <thingee> No one has really given me a reason why approach is a problem except that the driver has access.
16:31:35 <hemna> I'm on the fence about it
16:31:46 <eharney> until we have a more general solution for how to do this type of thing, i'm not that concerned about eliminating it in cases that aren't problematic just for the sake of it
16:31:47 <thingee> why my approach*
16:31:47 <jgriffith> thingee: sorry... can you expand on your comment?
16:32:09 <jgriffith> thingee: ohh... got it
16:32:15 <jgriffith> didn't see the next comment yet
16:32:18 * jgriffith reads slowly
16:32:26 <jgriffith> thingee: eharney fair enough
16:33:40 <thingee> if anyone wants to read my comment, it's the last one here https://review.openstack.org/#/c/107693/14/cinder/volume/manager.py
16:34:21 <bswartz> thingee: you're in favor of allowing a driver to make a DB call just this once?
16:34:37 <jgriffith> thingee: I'm kinda confused now... that seems pretty close to what I have been saying all along?
16:34:45 <thingee> yes if no one sees a risk with it
16:34:49 <glenng> *is very confused*
16:34:50 <thingee> bswartz: ^
16:34:54 <jgriffith> thingee: just allows the call
16:35:01 <jgriffith> anyway...
16:35:04 <thingee> it's read only for something at start up
16:35:06 <bswartz> the risk is that others will use this as an example of why they should be allowed to use the DB inside their driver in the future
16:35:15 <jgriffith> bswartz: +10000
16:35:17 <bswartz> the team will have to be vigilant against that possibility
16:35:33 <jgriffith> bswartz: and historically we're not very vigilant
16:35:33 <hemna> yup :(
16:35:36 <DuncanT-1> I'd like to look at fixing up all the other instances too
16:35:43 <thingee> bswartz: I can see that as a good point
16:35:57 <DuncanT-1> Hard to tell people they can't do it when we're letting it happen in other place though
16:36:03 <jgriffith> #proposal  just merge the patch and address better ways to do it going forward
16:36:19 <eharney> the method in the patch isn't what we're leaning toward here
16:36:19 <bswartz> I think we assumed that allowing database access in the driver was a SUPER EVIL thing to do and thus designed this somewhat awkward workaround
16:36:33 <eharney> still need to get glenng's last comments in sync with a consensus here
16:36:35 <jgriffith> add a comment # DONT DO THIS, this is a special case
16:36:35 <xyang1> driver calls DB in a lot of places today.  If we want to discourage that, we should document it somewhere.
16:37:06 * jungleboyj needs to drop off to get my boy from school.
16:38:05 <bswartz> so we need a decision to merge or to do yet another change cycle on this one
16:38:12 <eharney> it's not ready to merge
16:38:20 <bswartz> eharney: why not?
16:38:22 <DuncanT-1> Merge it. There are 22 other cases to fix, one more doesn't make much odds
16:38:33 <DuncanT-1> Including the LVM driver
16:38:34 <eharney> because the patch that's posted now isn't even doing the method we are talking about allowing
16:38:52 <jgriffith> bswartz: the patch now is more what I liked
16:39:04 <glenng> So using the kwargs to pass the information from the VolumeManage to the driver does seem like a viable solution if we want to keep DB calls out of the driver.
16:39:06 <jgriffith> bswartz: but people don't like that a function is getting called that returns False most of the time
16:39:20 <hemna> glenng, +1
16:39:27 <glenng> jgriffith: That is a different issue from how we get the DB info to the driver.
16:39:44 <jgriffith> glenng: well.... ummm.... ok
16:39:47 <glenng> We will still have to have the volume driver check if the actual driver is secure.
16:39:52 <thingee> glenng: I think that's what we'll have to go with. I don't like the approach personally, but others seem to favor it
16:39:57 <eharney> jgriffith: yeah i don't want everyone showing up in six months complaining about remotefs-specific warts in the manager
16:39:59 <glenng> The volume driver is performing file operations.
16:40:15 <DuncanT-1> I prefer the kwargs option, it's cleaner, but I'll no longer get overly upset if the db in the driver approach is used
16:40:18 <jgriffith> eharney: that's probably good thinking
16:40:27 <jgriffith> eharney: especially since I'd be the first to bitch about it :)
16:40:46 <DuncanT-1> eharney: If we get to the point that those are our worst warts in six months time, I'll be very happy
16:40:54 <bswartz> so what I hear is that everyone is okay with the current patchset except eharney
16:40:58 <jgriffith> glenng: DuncanT-1 we've used kwargs in numerous places and IMO I think it's a clean solution
16:41:15 <jgriffith> bswartz: not completely
16:41:15 <DuncanT-1> jgriffith: I prefer it
16:41:30 <jgriffith> bswartz: and eharney makes a pretty strong point
16:41:38 <thingee> #agreed kwarg approach is it, the volume manager will query if there are any volumes that exist per backend.
16:41:39 <glenng> So, we wnat kwargs over DB lookupin driver. Correct all?
16:41:41 <jgriffith> I think one last spin using kwargs is good
16:41:53 <thingee> #agreed db look ups of any kind from the driver is bad
16:42:06 <glenng> Okay, do we want the operations moved into RemoteFS?
16:42:13 <thingee> glenng: yes
16:42:15 <eharney> there are still other finer points being reviewed in there so don't go +Aing the next patchset too fast :)
16:42:39 <jgriffith> eharney: why are you looking at me :)
16:42:46 <glenng> OK, then that leaves the last item of volume driver must have a new method to ask driver if it is secure. Okay?
16:42:47 <eharney> jgriffith: just to whoever
16:42:56 <jgriffith> eharney: I know... I was kidding
16:43:08 <jgriffith> everybody is so darn stuffy lately
16:43:17 <glenng> Volume driver will call it and most will say False. NFS and maybe remoteFS could say True.
16:43:21 <eharney> glenng: that will be internal to the driver right?
16:43:47 <glenng> eharney: The override of the method would be driver specific. This is how a driver would become secure.
16:44:08 <glenng> Otherwise the base method says False when called.
16:44:11 <DuncanT-1> Can I hate on the name 'secure' for a minute?
16:44:11 <jgriffith> glenng: eharney base method in block drivers just auto return false?  base method in shares drivers makes the call maybe?
16:44:15 <jgriffith> glenng: ok
16:44:27 <eharney> I'd make it a property rather than a method personally
16:44:33 <glenng> Hate away but it is accurate ;-)
16:44:34 <eharney> but the idea makes sense
16:44:36 <DuncanT-1> Other than the name, I'm happy enough
16:44:46 <bswartz> duncant: do you have a better term?
16:44:54 <flip214> eharney: it might depend on the specific configuration.
16:44:59 <DuncanT-1> bswartz: Erm, working on it
16:45:02 <eharney> flip214: that's fine
16:45:04 <bswartz> the name doesn't thrill me but no better name ever crossed my mind
16:45:20 <glenng> eharney: And ther may be different checks to determine if operating in secure mode.
16:45:28 <DuncanT-1> bswartz: I'm struggling, I just don't like the idea of most drivers claiming not to be secure
16:45:39 <DuncanT-1> secure_mode_needed?
16:45:48 <DuncanT-1> bswartz: It
16:45:52 <eharney> glenng: flip214: it's a boolean return describing the state of how it's setup.  @property is perfect for that, it can do the same thing the method does
16:45:56 <eharney> but no need to get hung up on that
16:46:19 <DuncanT-1> bswartz: It is a minor concern, not going to block anything on it, just expressing my distaste
16:46:31 <thingee> eharney, DuncanT-1: on these particular details, I would like to defer them to #openstack-cinder, but I think we're agreeing on a approach, which is great!
16:46:46 <glenng> DuncanT-1: Option now will be nas_secure_file_operations. Is that okay?
16:46:47 <DuncanT-1> thingee: Agreed
16:46:53 <DuncanT-1> glenng: Perfect
16:46:58 <DuncanT-1> glenng: Thanks!
16:47:05 <thingee> awesome, thanks everyone
16:47:16 <glenng> DuncanT-1: and the other options will be nas_secure_file_permissions.
16:47:21 <thingee> #topic Kilo Stabilization
16:47:31 <thingee> #link https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
16:48:00 <thingee> For the most part, the high priority items are picked up. There are some new higher priority items that were recently added that have not been verified
16:48:30 <hemna> do we have specs for each of the items picked up yet?
16:48:54 <hemna> I think Duncan is going to give us one for the rolling upgrade soon.
16:49:13 <thingee> hemna: state machine: check, rolling upgrade: coming soon from duncan, scalability: has a dependency on state machine
16:49:38 <hemna> the Fix database abuse and scalability items seem very open ended.   It would be nice if we had some concrete approaches for helping achieve those goals.
16:49:50 <eharney> i was just thinking the same thing re: database
16:49:59 <thingee> hemna, eharney: +!
16:50:03 <thingee> +1 even
16:50:04 <thingee> whoa
16:50:26 <thangp> i thought there are plans to make cinder objects to fix the db abuse
16:51:04 <thingee> thangp: what does that mean?
16:51:20 <DuncanT-1> Just reviewing all the queries we generate is a start, make sure we don't have anymore of the queries-per-record things we had going on
16:51:22 <thangp> jgriffith, mentioned it above...
16:51:29 <jgriffith> thingee: the volume objects piece
16:51:31 * thangp scrolling back to fine it
16:51:38 <hemna> thangp, the volume objects piece was for state mgmt
16:51:43 <thangp> ah ok
16:51:48 <jgriffith> thingee: rather than call the db 100 times in the process of a volume create gettting the ref over and over and over
16:51:58 <thingee> gotcha
16:51:58 <jgriffith> thingee: it's actually both :)
16:52:17 <jgriffith> thingee: thangp also some of that I started by getting rid of the stupid:
16:52:23 <DuncanT-1> Helps with schema upgrade on a live system too
16:52:27 <jgriffith> db.volume_update; db.volume_get
16:52:34 <jgriffith> since the update returns an updated ref
16:52:51 <jgriffith> Why would we then immediately do a get on what we just updated :)
16:52:54 <jgriffith> stuff like that
16:52:56 <DuncanT-1> Note that several attempts to optimise db accesses have resulted in later bugs though...
16:53:05 <DuncanT-1> And I don't understand half of them
16:53:06 <jgriffith> we need to cull all of that sort of crap out as a start IMO
16:53:07 <thingee> so I really think we're in good shape with what we want to accomplish this release. I think state machine and rolling upgrades are going to need to help from everyone, not just the people leading it, so I'd rather not get everyone too over subscribed
16:53:52 <hemna> thingee, I can look into the sqlalchemy db sql dumps
16:54:02 <hemna> and see if I can at least get a list of the queries
16:54:45 <rushiagr> I'd like to volunteer myself if any help is needed w.r.t. DB related work
16:54:48 <thingee> I'll review and encourage others to review what's being posted on there, and if you don't see a bp/spec for it and interested in helping out, please propose away!
16:54:55 <thingee> hemna: awesome, thanks
16:55:14 <thingee> https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
16:55:24 <e0ne> hemna: i could help with sqlalchemy profiling
16:55:32 <hemna> e0ne, cool :)
16:55:35 <thingee> #topic Cinder Kilo Specs
16:55:58 <hemna> thingee, so I plan on filing one about brick work.  I just haven't gotten around to it yet.
16:56:09 <thingee> hemna: ok
16:56:11 <hemna> re: extracting brick from cinder to a pypi lib.
16:56:23 <thingee> #link https://review.openstack.org/#/q/status:open+project:openstack/cinder-specs,n,z
16:56:48 <xyang1> hemna: and a spec for cinder agent too?
16:57:00 <hemna> I've been helping our horizon team write up some specs about UX changes for horizon<-->cinder integration
16:57:05 <thingee> I think we're all doing a great job keeping these going. I have went through half of them and will follow up on those and go through the other half today.
16:57:12 <hemna> xyang1, yah
16:57:16 <thingee> I encourage others to chime in to help us make a decision on these
16:57:51 <thingee> Ideally I would like specs figured out sometime by this month
16:58:06 <kmartin> thingee: we have the code already for a leftover Icehouse/Juno BP https://blueprints.launchpad.net/cinder/+spec/filtering-weighing-with-driver-supplied-functions
16:58:14 <xyang1> thingee: are you saying no more specs after this month?
16:58:28 <kmartin> should we enter a cinder-spec for it as well?
16:58:37 <xyang1> kmartin: when are you going to submit code?
16:58:38 <hemna> kmartin, yes
16:58:39 <thingee> xyang1: ideally. we'll have to see how specs are going and adjust
16:58:53 <hemna> kmartin, since it would be a new scheduler feature for kilo.
16:59:19 <flip214> war^Wmeeting is over
16:59:20 <kmartin> it was well documented in the BP and already approved
16:59:30 <xyang1> I'm going to submit a spec to allow over subscription in thin provisioning
16:59:32 <thingee> kmartin: for code already done, I say specs are still useful. Again referencing the nfs sec enhancement stuff. it would've been good to know the approach instead of arguing over gerrit
16:59:38 <thingee> ok we're out of time.
17:00:04 <thingee> #endmeeting