22:04:38 #startmeeting db 22:04:39 Meeting started Thu Jan 24 22:04:38 2013 UTC. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:04:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:04:42 The meeting name has been set to 'db' 22:05:15 I don't have an agenda or anything :) 22:05:44 but some really cool patches have landed recently, so I thought might be good to talk about the next steps 22:05:52 or see what everyone else is doing 22:06:00 #topic open discussion 22:07:14 so, support for unique indexes landed yesterday 22:07:38 #link https://review.openstack.org/16940 22:07:48 and it looks like shadow tables // archiving is about to land 22:08:01 #link https://review.openstack.org/18493 22:08:06 devananda: awesome 22:08:14 so now we can start using unique indexes? 22:08:17 yep 22:08:21 rather start enabling them 22:08:30 Boris is planning to create one review / migration per table 22:08:40 sweet 22:08:41 to add actual unique constraints, and test the migration fwd/bkwd 22:09:25 devananda: as there are some big changes to DB landing for Grizzly, perhaps it would be nice to send an email out to openstack-dev saying what has changed, and what is coming 22:09:42 to let people know that the DB is getting better 22:09:52 and how many cool things have landed 22:09:57 probably a good idea :) 22:10:18 there's also the no-db-compute stuff which seems to be slowing down a lot 22:10:38 though i haven't followed it closely 22:10:54 not sure how far they are on that one, but looks likes its made a lot of progress 22:11:02 russellb: ^ 22:11:42 so lets review the big cahnges that have landed so far 22:11:57 and what is still scheduled 22:12:12 so we have the basics for a email 22:12:18 k 22:12:36 russellb: does reviewday do a topo sort (e.g. all reviews in a stack get promoted to the highest importance of the reviews under it? 22:13:00 lifeless: no idea on that 22:13:03 dprince wrote it 22:13:07 question: plans to support stuff else then mysql ? 22:13:09 on no-db-compute, still some work to do 22:13:24 I have a review up that hacks nova-compute to log a traceback every time db.anything gets called 22:13:24 zykes-: afaik postgres is already supported 22:13:38 oh 22:13:45 still looks like we can do it by grizzly-3, but have to work at it 22:14:03 I added postgres CI tests 22:14:20 russellb: would be great to have a status page that listed the db calls still coming from n-cpu :) 22:14:22 postgres is used on smokestack as well 22:14:39 devananda: heh, yeah ... it's basically the nova-compute log from the latest test run on that review right now 22:14:57 heh 22:15:25 for reference ... https://review.openstack.org/#/c/20052/ ... http://logs.openstack.org/20052/7/check/gate-tempest-devstack-vm/27998/logs/screen-n-cpu.txt.gz 22:16:06 jog0: the meeting wiki seems to be the best reference right now for ongoing DB work at a high level: http://wiki.openstack.org/Meetings/DBTeamMeeting 22:16:09 105 entries in that log file (many of them the same thing) 22:17:07 devananda: yeah, most of those are in progress AFAIK 22:17:11 if not all 22:17:23 yea 22:17:55 although I did file a bug on non-blocking-db 22:18:01 with comstud 22:19:03 going to jot down my understanding of the different project status' here: https://etherpad.openstack.org/db-status 22:19:21 and use that as a basis for an email 22:19:23 sounds good 22:19:50 russellb: so postgresql in tempest gate is currently bust, you know if dprince is running all the tests or just smoke? 22:20:16 sdague: i'm not actually sure ... 22:21:05 http://logs.openstack.org/periodic/periodic-tempest-devstack-postgres-vm-full/ if anyone wants to help sort out the fails, wanted to get that actually gating by g-3 to keep us sane 22:21:33 sdague: I'll take a look at postgres failures. 22:21:44 sdague: if you go to smokestack.openstack.org, scroll down to a nova patch, you should be able to dig into the logs for a given run that was using postgres 22:21:51 dripton: hey there :) 22:22:13 dripton: I think I got the whitebox one addressed in review, but there is a floating ips one, they are usually type mismatch issues 22:22:15 he may have tempest disabled, not sure 22:22:24 russellb: ok 22:22:43 sorry, just figured I'd stick that out there as I saw the pg statement 22:22:48 sdague: i'm not actually seeing tempest in the log file right now 22:23:14 dripton: I +1'd your shadow-table patch. is there a patch for copying deleted rows to them? 22:23:34 devananda: not yet; I was waiting for the first part to go in first. But I think it'll be easy. 22:24:33 dripton: great. if it's easy, i think it would be good to have the copy-deleted-rows patch up to get feedback on it 22:24:50 the particulars of that were a bit of a hot topic at the last summit, IIRC 22:25:20 Will do. I wanted to make sure the shadow tables were okay with people first. If they are then it's straightforward copying. 22:25:27 devananda: dripton +1. It would be nice to be able to try out the shadow tables with copying deleted rows before merging the migration 22:25:41 ++ 22:26:03 ok, I'll try to get the copying patch up soon. (If it's as easy as I think, maybe tomorrow.) 22:26:40 devananda: lets add impact to the ehterpad 22:32:26 devananda: looks good 22:32:38 awesome, thx :) 22:32:42 there are definitely some nice changes in there 22:32:53 lots of exciting stuff for Grizzly 22:34:25 Does that etherpad auto-save? The one I use most has a save button. 22:34:45 AFAIK yes 22:34:55 dripton: yes. click the history button to see 22:35:42 any other topics folks want to bring up? 22:35:59 devananda: yeah 22:36:13 haven't finished collecting/parsing the logs yet 22:36:39 but think I found an example where mysql reports it takes 0.003156 second and nova.db.api takes 0.08 seconds 22:37:11 but I will collect those logs and pastebin them when I double check 22:37:59 sounds good. an occasional skew of 0.05s doesn't surprise me too much in a cloud env 22:38:03 unless it's consistent 22:38:39 devananda: well I have very verbose logs this time so maybe we can make something of it 22:38:45 :) 22:39:36 devananda: this is related to finding out why some REST API commands take over a second 22:40:17 right 22:41:42 if there's nothing else, shall we end meeting a bit early? 22:41:47 +1 22:41:56 +1 22:42:04 great. thanks all! 22:42:07 bye 22:42:08 #endmeeting