21:00:07 #startmeeting nova_cells 21:00:08 Meeting started Wed Jun 10 21:00:07 2015 UTC and is due to finish in 60 minutes. The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:11 The meeting name has been set to 'nova_cells' 21:00:29 o/ 21:00:31 \o 21:00:33 o/ 21:00:38 o/ 21:00:43 o/ 21:00:59 #topic Tempest testing 21:01:15 melwitt: the floor is yours 21:01:38 nothing new this week, logstash link for the job is http://goo.gl/b7R8wq 21:02:04 looks to be in the same expected state, the patch for the undelete is still up at https://review.openstack.org/176518 21:02:43 the other race condition patch https://review.openstack.org/188126 merged last night so that's cool 21:02:43 there was some discussion at the end of that one 21:02:49 oh, nice 21:03:03 are you good on https://review.openstack.org/176518, or still unsure about it 21:03:32 well 21:04:19 I'm +1 because the trade-off would look like more benefits than debt 21:04:42 I guess overall, we can't get the same behavior it had, I think. it intended to create an instance row if there wasn't one found (because read_deleted="yes") 21:05:05 it intended to ignore InstanceInfoCacheNotFound. now we have instance.save() doing a lot of things inside it, which can raise NotFound 21:05:28 melwitt: yup that's my point 21:05:52 melwitt: it could still be raising a NotFound, but I think it's okay 21:06:14 is a create going to undelete something it shouldn't? 21:06:23 because there is a big except exc.NotFound: 21:06:28 if not then it seems fine as is 21:08:03 I think my concern is around, if we get NotFound for something other than InstanceNotFound, we would instance.create(). I don't know if maybe it should be like catch InstanceNotFound, create if that, else if it's other NotFound, pass 21:08:52 I don't know if that can really happen, I haven't seen it 21:09:04 mmm 21:09:12 I like that approach 21:09:57 okay, I can do that. 21:10:21 cool, I just backed off to a +1 for now 21:10:30 fair 21:11:26 I'll update it in a few. that's all I have on the testing, once this patch merges I'll be watching for a drop in job failures, and if that continues X amount of time we'll make it vote? 21:11:26 I noticed on the logstash link that failures are down to about 5 a day or less for the last 4 days 21:11:37 melwitt: that's the plan 21:11:44 cool 21:12:23 thanks for the update 21:12:33 #topic Specs 21:12:42 https://review.openstack.org/#/c/190209/ 21:13:01 I wrote up a devref change walking through how some things will work with cells v2 21:13:19 and included relevant specs for changes needed, and pointed out where specs are missing 21:13:32 that's a DNM ? 21:13:54 it's subject to change based on spec feedback 21:13:55 alaski: are you still -W it ? 21:14:01 alaski: oh ok 21:14:22 if it seems useful I'm not against it merging, but that wasn't my intention 21:15:06 it was more an exercise for me to see the gaps in specs, and to point people to when they ask why a spec is proposing a thing 21:15:35 fair point 21:16:08 cool, good to have 21:16:47 and it's a good medium for feedback which is why I chose it over an etherpad 21:17:37 belmoreira: any updates on the specs you have been working on? 21:18:01 alaski: not yet in that spec 21:18:25 today we proposed: https://review.openstack.org/#/c/190147/ 21:18:48 I added it to the meeting agenda 21:19:08 ahh, needed to refresh 21:19:51 I added it to the priorities etherpad for visibility 21:20:10 ah 21:20:16 flavors, mmm ? :) 21:20:22 great 21:21:07 now that I have a list of gaps I'm going to go crazy proposing specs soon 21:21:15 heads up 21:21:21 anything else on specs? 21:22:00 #topic Open discussion 21:22:19 anyone have a topic for open discussion? 21:22:40 * bauzas was off for the last 2 days so pass 21:23:18 the only spec approved right now is the host_mapping one so that limits the amount of coding for the moment 21:23:32 there's also the persist request spec one I guess, but that's blocked atm I think 21:24:14 so that just leaves specs to write, and docs 21:24:29 that's it from me 21:24:32 I did some review on one today 21:24:35 the flavors one 21:24:53 nice 21:24:53 it punted on migration, but it seems like we might as well include that in the spec since it's critical 21:25:30 I did set a precedent of splitting the table creation and migration 21:25:48 dansmith: yes, it's a fair point. The migration plan should be added 21:25:51 but now that the database is in place that may not be the right path 21:26:47 well 21:27:28 in this case I think it's important because we'll need to migrate them before we can switch over, 21:27:35 where the instance mapping is kindof a cache at this point 21:27:56 just seems like this one should be "move flavors from here to there" 21:28:20 yeah, I agree with that 21:28:31 there was a lot more about how to create the database in the first specs adding tables 21:28:43 now that it's there, the interesting bit is moving data 21:28:52 agreed 21:28:55 yes, I agree 21:29:33 oh, also 21:29:39 cool. I'll also take a look at the spec, but probably tomorrow 21:29:42 I started on the patch to make devstack (and then grenade) create the api db 21:29:51 it was failing on something, I haven't looked why, 21:29:56 but at least that is started 21:30:18 https://review.openstack.org/190289 21:30:32 gotta have that in devstack and then a change to grenade 21:31:09 very nice 21:31:24 cool indeed 21:31:25 oh, heh I just failed bashate 21:31:28 I think I can handle that :D 21:32:49 it's great to see more reviews up 21:32:55 anything else from anyone? 21:33:32 #endmeeting