22:04:10 <devananda> #startmeeting DB team meeting
22:04:10 <openstack> Meeting started Thu Nov  8 22:04:10 2012 UTC.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:04:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:04:12 <openstack> The meeting name has been set to 'db_team_meeting'
22:04:33 <devananda> hi all. busy afternoon :)
22:04:37 <devananda> who's sticking around?
22:04:39 <jog0> o/
22:04:41 <dripton> hi
22:05:23 <russellb> hi
22:05:53 <devananda> shall we touch on the action items from last week before going into the regular items?
22:06:08 <dripton> If we can do it faster than last week
22:06:26 <devananda> k
22:06:39 <devananda> i started some bp's for arranging the db cleanup
22:06:56 <devananda> we can probably add add'l nested bp's if needed
22:07:09 <devananda> i think jog0 made a list of leaking sqlalchemy objects
22:07:16 <jog0> devananda:  correct
22:07:35 <jog0> https://review.openstack.org/#/c/15450/ https://etherpad.openstack.org/sqlalchemy-leaks
22:07:48 <devananda> vish and i talked about the on-delete triggers and he'd rather shy away fromt aht for now
22:08:05 <devananda> using the UNIQUE (column, deleted) approach that someone suggested at the summit
22:08:23 <devananda> dripton was going to look for unused api calls. anything there?
22:08:27 <jog0> sounds like a good first step
22:08:32 <dripton> I dropped a patch for review today
22:08:43 <dripton> but it conflicts with another patch, so I'm waiting in line
22:08:43 <devananda> awesome
22:08:55 <dripton> There were a bunch
22:09:15 <devananda> i'll take a look at them tonight
22:09:40 <devananda> think that's all of last week
22:10:06 <devananda> main topics are db cleanup and no-db-compute
22:10:26 <devananda> i've moved archiving under cleanup, as that just seems related to me
22:10:59 <devananda> jump on in if you have things to say about ^ :)
22:11:06 <russellb> no-db-compute is chugging along.  dansmith is helping a bunch.
22:11:28 <russellb> none of it really affects the db layer code
22:11:44 <russellb> but we're doing a huge pile of moving around what code uses the db layer :)
22:11:50 <russellb> but let us know if you  have any questions/concerns about what we're up to
22:12:28 <devananda> russellb: i haven't been able to keep up with all the patches...
22:12:35 <russellb> yeah, it's a lot
22:12:39 <devananda> but what i've seen have been good
22:12:43 <russellb> they generally fall into 1 of 2 categories right now
22:12:58 <russellb> 1) moving db accesses happening in nova-compute up to nova-api, and having more data sent in the messages
22:13:35 <russellb> 2) pulling db accesses out of the virt drivers and into the compute manager code so that it's all in one place
22:13:39 <dansmith> 2 is about done
22:13:46 <russellb> dansmith: awesome!
22:13:50 <dansmith> there's a single db.foo query left in nova/virt
22:14:00 <dansmith> not including any obscure magical db references, which will be harder to find
22:14:02 <russellb> not a whole lot left of 1 either ... a few probably
22:14:08 <dansmith> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/no-db-compute,n,z
22:14:32 <devananda> so, my other hat -- we'll have to go do that work for baremetal as well
22:14:44 <devananda> a fair bit of db access in virt/baremetal
22:14:44 <russellb> ah, yeah ...
22:14:59 <dansmith> yeah, I should help look for those in the pending reviews
22:15:03 <devananda> but most of it is accessing the bm db, not nova, iirc
22:15:07 <russellb> well it's actually not as impotant for virt/baremetal, really
22:15:13 <russellb> right, its own db
22:15:20 <russellb> and there aren't guest VMs running on the compute machine
22:15:26 <devananda> right
22:15:39 <dansmith> but trying to stick to the pattern of the others would be nice
22:15:42 <russellb> so, some of the optimizations could apply if it's adding new rpc stuff
22:15:44 <dansmith> at least for auditing issues, I think
22:15:57 <russellb> dansmith: true ... but i'm not sure how that would work if each nova-compute has its own db in barematal land
22:16:05 <russellb> (which some people have objected to btw)
22:16:06 <dansmith> russellb: not for the baremetal db,
22:16:11 <dansmith> I mean for the regular nova db stuff
22:16:12 <russellb> oh, right
22:16:17 <russellb> +1 to that then
22:16:23 <devananda> >1 nova-bm-compute can share one nova_bm db, i believe
22:16:34 <russellb> ah...
22:16:49 <russellb> but still, security concern doesn't apply in the same way, so *shrug*
22:16:54 <devananda> cool
22:17:09 <russellb> still the upgrade side of it though ...
22:17:20 <dansmith> yeah
22:17:23 <russellb> more than one service talking to the same db, and you want to live upgrade them
22:17:33 <dansmith> that impossible pie-in-the-sky goal :)
22:17:34 <russellb> fun times
22:17:44 <russellb> heh, we'll get there someday
22:18:08 <devananda> if you can take a look at the bm patches and give me some feedback on removing db access, that'd be apprciated :)
22:18:19 * russellb puts it on "the list"
22:18:22 <russellb> the list has been too big lately :(
22:18:27 <devananda> *nod*
22:18:29 <russellb> same problem for us all
22:19:31 <dripton> Just FYI, I took a look at alembic for backportable DB migrations
22:19:51 <dripton> Wrote a script to convert most of our migration scripts from sqlalchemy-migrate to alembic, which mostly works.
22:20:02 <dripton> But I don't think I'll push it further until we *need* it.
22:20:37 <devananda> my feeling is that'd be good before we need it
22:20:53 <devananda> eg., if there's some major bug that requres a db migration back-port
22:21:01 <devananda> waiting for alembic at that point might be rough
22:21:04 <devananda> no?
22:21:30 <dripton> True.  Maybe I'll start pushing sooner.  I'm waiting for Dan Prince to squash Folsom migration scripts.
22:22:14 <russellb> dripton: have you asked him about that?
22:22:17 <russellb> is he working on it?
22:22:38 <dripton> russellb: Yes, he wants to do it. I don't know if he's actually started, but he didn't want me to take it off his plate.
22:23:02 <russellb> gotcha
22:24:04 <devananda> anyone from db-common here today?
22:25:12 <devananda> #topic open discussion
22:25:46 <jog0> devananda: so we are going with UNIQUE (column, deleted) as a first pass?
22:26:11 <devananda> jog0: that seems to be the shorter path to getting away from some of the race conditions
22:26:34 <devananda> actually, i was looking at postgres last night and it looks like they dont support INSERT .. ON DUP KEY UPDATE
22:27:10 <jog0> so we may be forced to abandon the shadow table idea then?
22:27:23 <dripton> Is there an equivalent workaround for postgres?
22:27:49 <devananda> dripton: afaict, not really knowing postgres, the answer is "no"
22:27:58 <jog0> well doing UNIQUE (column, deleted) sounds good to me.  DOo we want to aim for Grizzly-1 for this?
22:27:59 <devananda> atomic "upsert" as they call it isn't possible
22:28:05 <russellb> i'm happy to see an active db team, thanks guys :)
22:28:14 <dripton> I found a stack overflow post showing how to do it using exceptions, but it's ugly
22:28:28 <devananda> yea, i found several examples using functions, exceptinos, etc... all ugly
22:28:31 <devananda> and none solvethe race condition
22:28:50 <devananda> jog0: i think we should gather a list of places where it's appropriate to apply UNIQUE indexes
22:29:16 <jog0> sounds good, how about an action item for next week
22:29:39 <devananda> #action devananda to create list of methods that enforce uniqueness // tables that need UNIQUE indexes
22:30:05 <devananda> i already have some notes on that, so it shouldn't take long to clean up
22:30:10 <jog0> as this will be a pretty big change to the way things work the longer its in trunk the better
22:30:53 <jog0> also vishy had an interesting suggestion about sqlalchemy leaks (https://review.openstack.org/#/c/15450/) and  I will be trying it out for next week. (my action item for next week)
22:31:56 <devananda> #action jog0 continue plugging leaking sqlalchemy objects
22:32:46 <jog0> dripton:  did you find any read_deleted low hanging fruit?
22:33:14 <dripton> jog0: no, I did not.  It was all high-hanging fruit
22:33:15 <devananda> jog0: any update on the benchmark logs?
22:33:46 <jog0> dripton: too bad,  can you make a list so we can plan on how to attack them
22:34:13 <jog0> devananda: not yet.  let me check if I saved the old log files though
22:34:22 <dripton> jog0: I will make a list of read_deleted instances.
22:34:35 <jog0> dripton:  thanks
22:35:39 <jog0> devananda:  I found some old log files that I saved,   I can send them to you after the meeting
22:35:41 <devananda> dripton: probably good to link that from one of the db-cleanup whiteboards
22:35:48 <devananda> jog0: great, thanks
22:35:54 <dripton> devananda: ok
22:35:59 <jog0> they are pretty big, a few MBs
22:36:04 <jog0> so pastebin may not work
22:36:38 <devananda> #action dripton post a (link to a) list of read_deleted instances to db-cleanup whiteboard
22:36:59 <devananda> jog0: hm. we all have servers in clouds somewhere, right? :)
22:37:08 <devananda> or google drive or something
22:37:26 <devananda> if it's small enough to email, that's fine too
22:37:45 <jog0> devananda: yeah,  I have to review them to  give you some context and then I will put them on google drive or email
22:38:19 <devananda> ack
22:40:00 <devananda> anything else, or shall we wrap up a bit early?
22:40:42 <dripton> That's all I have.
22:41:17 <jog0> same
22:41:30 <devananda> thanks everyone
22:41:31 * dripton waves goodbye
22:41:34 <devananda> #endmeeting