17:00:17 #startmeeting nova_cells 17:00:18 Meeting started Wed Jul 1 17:00:17 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:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:22 The meeting name has been set to 'nova_cells' 17:00:38 o/ 17:00:42 \o 17:00:46 o/ 17:00:48 o/ 17:01:27 not much on the agenda today, hopefully we can run through quickly 17:01:32 #topic Tempest testing 17:01:44 melwitt: I hear there's good news 17:01:44 o/ 17:02:01 yes, as of yesterday the tempest cells job is voting 17:02:15 * bauzas waves late 17:02:21 awesome 17:02:33 \o/ for the cells job 17:02:39 great work on that everyone 17:03:13 and the todo on that is to get the regex trimmed down and replaced with config options 17:03:47 did the necessary tooling for that all get merged? 17:03:55 melwitt: need some help for that ? 17:04:10 yes, the regex now lives in nova so we have control over it 17:04:20 awesome 17:04:38 bauzas: help is very welcome 17:04:52 melwitt: ok let's sync offline 17:05:17 this is where our regex is now https://github.com/openstack/nova/blob/master/devstack/tempest-dsvm-cells-rc 17:05:43 #link https://github.com/openstack/nova/blob/master/devstack/tempest-dsvm-cells-rc 17:05:53 that's great 17:06:14 that's all I have on the tempest testing 17:06:15 so, let's work on Tempest :) 17:06:29 melwitt: thanks 17:07:29 That's amazing work, and a huge milestone to get to this point 17:07:39 #topic Specs 17:07:57 as always there are a few specs to look at 17:08:08 https://review.openstack.org/#/c/190147/ https://review.openstack.org/#/c/194935/ are the ones on the agenda 17:08:47 has anything else come up? 17:08:58 or is there anything anyone would like to discuss on them? 17:09:12 alaski, is 190147 okay? does it need to cover everything else? 17:09:34 john reviewed it a few hours ago with a +2. 17:09:39 vineetmenon: I will need to go through it again 17:09:52 vineetmenon: I'll review it asap 17:09:55 okay. cool. 17:10:30 alaski, bauzas, he was asking about soft-delete functionality.. 17:10:49 remove soft-delete, specifically 17:10:55 vineetmenon: that's a very good question 17:11:21 vineetmenon: on my own, I think it's okay to say that you can just check with lxsli when it's done 17:11:37 that might be something to raise in the Nova meeting 17:11:52 I would say to punt on it for now and not change tables as they're migrated, other than the rename 17:12:04 vineetmenon: I mean, depending on either you or lxsli for the soft-delete does first, then the other will rebase 17:12:10 but I'm also good with removing soft-delete 17:12:16 alaski, bauzas: so nothing about soft delete yet, right 17:12:20 alaski: agreed, let's just comment it 17:12:26 vineetmenon: that would be my preference 17:12:38 cool. no issues 17:12:52 vineetmenon: if you need a new PS, maybe just leaving a phrase saying that deleted is not really needed is good 17:13:22 anyway, I don't want to see this spec unmerged because of that 17:13:29 sounds yakshaving 17:13:45 bauzas, alaski: IMO, it would better if either of you guys do that.. 17:13:46 we know that we need to remove the deleted fields 17:13:48 yeah. I think it can be addressed later 17:14:05 commenting, i mean 17:14:06 vineetmenon: let me just comment johnthetubaguy's comment 17:14:18 s/comment/reply 17:14:23 bauzas: yeah 17:14:45 anything else for specs? 17:15:11 #topic Open Discussion 17:15:11 I have a question about how https://review.openstack.org/#/c/194935/ will look 17:15:19 #undo 17:15:20 Removing item from minutes: 17:15:40 melwitt: you mean the implementation of it? 17:16:03 alaski: yes I think 17:16:59 pardon the ignorance but my understanding is we won't have cells_api anymore so how do we know where to use the "with context..." manager around instance object stuff, or will we have to have it everywhere in the normal nova code base? 17:17:30 for it to get the database connection string 17:18:08 melwitt: it shouldn't need to be used everywhere 17:18:20 I thought it was done by the context ? 17:18:42 melwitt: within a cell it won't be needed at all, unless we add calls back up to the api 17:19:03 and that boundary is between the api/conductor and cell conductor/manager 17:19:09 nvm, didn't read the spec yet... 17:19:12 poorly worded there, but the boundary should be clear 17:19:43 alaski: okay, that's what I wasn't clear about is what the boundary will look like in v2 or if there would be one at all. cool 17:19:48 the only time it should be necessary is when a request has to go from the api to a cell db, which should be relatively infrequently 17:20:57 melwitt: yeah, there will be a boundary. I hope it can evolve over time, but for now it will be the rpc calls from api to conductor/compute 17:21:19 and potentially a conductor we're adding at the api level 17:22:02 alaski: is that explained more in a spec or other doc that I missed? 17:22:15 commented in some specs actually... 17:22:34 melwitt: not that clearly, but some is mentioned in https://review.openstack.org/#/c/141486/ about a new conductor being deployed 17:22:39 in particular the api-conductor thing 17:22:47 jinxed by alaski with details 17:22:51 cool, thank you both 17:22:53 melwitt: that would be a good thing for me to add to the devref 17:23:55 #topic Open Discussion 17:24:15 any topics for open discussion? 17:24:23 alaski: I tried addressing points you raised about https://review.openstack.org/#/c/192098 17:25:06 dheeraj-gupta-4: great, I'll look at that in a bit 17:25:30 no problem 17:26:25 if nothing else we'll close early 17:27:06 cool. thanks everyone! 17:27:12 #endmeeting