17:00:27 #startmeeting nova_cells 17:00:28 Meeting started Wed Apr 22 17:00:27 2015 UTC and is due to finish in 60 minutes. The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:32 The meeting name has been set to 'nova_cells' 17:00:50 o/ 17:01:21 sweet, it's not just me :) 17:01:33 hehe 17:01:49 bauzas: o/ 17:02:01 o/ 17:02:04 #topic Tempest testing 17:02:21 so... things are green! 17:02:32 hooray 17:02:50 \o/ 17:03:01 I'd like to get a few days of data before we decide if it should vote 17:03:05 +1 17:03:13 but hopefully that's something we could do this week 17:03:26 o/ 17:03:50 so, let's just keep an eye out 17:03:58 but excellent work everyone 17:04:04 yeah, awesome 17:04:21 #topic Specs 17:04:40 I reviewed some specs 17:04:45 not enough, but some 17:04:53 hopefully enough to not be voted off the island 17:04:54 still helps 17:04:59 not yet 17:05:03 whew 17:05:28 the feedback on the requestspec object one led me to open a few more 17:05:40 sounds like I have to work on it soon :=) 17:06:01 before that, I want to co-ordinate a bit 17:06:09 alaski: feel free to review the already approved spec 17:06:19 alaski: I perhaps missed some things 17:06:21 sure 17:06:43 well, I've been thinking that we sort of want to persist it in two places 17:07:02 part of it in instance_extra, but then also in the api db 17:07:19 technically, there are possibly N instances for one RequestSpec 17:07:41 right, which would be stored N times in the api db 17:07:57 in the instance_extra ? I'm not that sure 17:08:10 so here's my thinking 17:08:30 we already have some problems with all the instance FKs, maybe something denormalized would be good 17:08:31 we want to store it in the api db before we have an instance, but then when we have a cell and instance we want to store it in the cell with the instance 17:09:08 * edleafe sneaks in late 17:09:33 yup, just a mapping table sounds good to me, nope ? 17:09:48 so, 17:09:52 if this requestspec is an object, 17:09:55 bauzas: mapping table to the request_spec? 17:10:00 it makes it easy to persist it in one place first, and then again elsewhere 17:10:10 i.e. we serialize it into an api db holding place, 17:10:13 dansmith: that's what I think 17:10:25 dansmith: and we sync it 17:10:29 and then when we create the N instances from it, we just serialize the thing to the instance_extra of each 17:10:32 sync it? 17:10:39 dansmith: right, that's what I was thinking 17:10:42 once the instances are created, we delete the api holding place 17:10:42 +1 17:11:13 we actually don't need the whole thing in instance_extra, just a few parts that aren't already a part of instance or instance_extra 17:11:28 well, 17:11:32 maybe 17:11:37 makes it easier if we have the whole thing 17:11:42 true 17:11:50 but if we can take a partial requestspec object, and fill in the gaps from the running instance 17:11:52 because I was about to say we'll need to hydrate from two forms 17:11:56 for things like a rebuild, then I guess that's okay 17:12:12 alaski: yeah, we could do that, if we plan for it from the beginning 17:12:57 I sketched out part of this in https://review.openstack.org/#/c/176078/1 so you all can tell me how crazy I am there 17:13:19 but we could also just persist it the same way in two places 17:13:45 is there any reason not to persist it same way? since that would be easier 17:13:52 just space 17:13:55 just that it's redundant 17:13:56 yeah 17:14:00 okay 17:14:01 otherwise it's much easier to just save the thing in the new place 17:14:15 we can also plan to just do the easy thing 17:14:21 and then if it looks like it's really worth it, 17:14:35 come up with a way to slim it down and partially hydrate it from the instance later 17:14:47 that works for me 17:14:49 more work, but the rule is optimize after it's working, so.. 17:15:04 so the second part is https://review.openstack.org/#/c/176083/ 17:15:21 not much there, but basically should we take the instance out of the requestspec 17:15:25 I think alaski is over his spec quota, who's with me? :) 17:15:37 dansmith: hah, I've not yet begun to spec 17:15:42 haha 17:15:43 dansmith: +1 17:15:44 heh 17:16:00 sorry on the phone 17:16:15 np 17:16:43 if we are going to persist the requestspec before we have an instance, it's helpful if there's not an instance in the requestspec 17:17:00 ack 17:17:04 aye 17:17:13 not that having an instance obj there means we can't serialize and persist, but it's also confusing 17:17:28 so my suggestion is to break that out into the pieces that the scheduler cares about 17:17:39 well, 17:18:13 you're saying this because of how requestspec currently works rightr? 17:18:26 like because it's a dict of an instance, that we create an instance from over and over? 17:18:34 right 17:18:36 or because the current requestspec object proposal has an instance field? 17:18:48 oh, that one 17:19:07 we shove an instance in there, but call it instance_properties 17:19:12 yeah we can fix it 17:19:22 what we need are just those properties 17:19:28 and perhaps it would be better to enumerate them 17:20:04 so, we just make requestspec.instance an @property 17:20:11 and generate the instance if asked, but don't store it 17:21:20 yeah, that works. I still feel like we should split instance_properties, but ultimately it's not the issue 17:21:30 probably 17:21:45 wait, 17:21:58 actually, we don't really need to generate an instance at any point 17:21:59 by split instance_properties, you mean "not store shit in there that we don't need for scheduling" right? 17:22:01 I don't think 17:22:15 dansmith: that, and store it as prop1, prop2, etc... 17:22:27 ? 17:22:30 prop1 huh? 17:22:43 I forget what's in there :) 17:23:13 I don't know what you mean by "and store it as prop1.." 17:23:32 requestspec.prop1/prop2 vs requestspec.instance_properties 17:23:34 oh you mean as requestspec.prop1 and not requestspec.instance.prop1 17:23:38 yes 17:23:41 do that :0 17:24:05 heh, cool 17:24:20 that means an update to bauzas spec, which I can put up 17:24:59 right 17:25:07 fair 17:25:20 still otp sorry 17:25:47 that was all I had on specs for the moment 17:25:54 anyone else have something? 17:26:23 #topic Open Discussion 17:26:30 or anything for general discussion? 17:26:56 not I 17:27:08 hope to have cells job voting by next meeting? 17:27:14 yes 17:27:19 pretty amazing, the future we live in 17:27:26 I'd like to bring it up in the nova meeting 17:27:29 dansmith: hah :) 17:27:32 alaski: cool 17:27:44 just an fyi: I've been working on the patch from long ago that passes a real instance object to cells instance_update_at_top which is part of converting stuff to objects 17:28:02 excellent 17:28:13 sweet 17:28:27 anything up to see yet? 17:28:43 not yet. I've almost got the unit tests passing with it 17:29:06 cool. please add me when it's up 17:29:17 will do 17:29:36 if nothing else, early marks 17:29:50 #endmeeting