17:00:00 #startmeeting nova_cells 17:00:01 Meeting started Wed Aug 30 17:00:00 2017 UTC and is due to finish in 60 minutes. The chair is dansmith. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:04 The meeting name has been set to 'nova_cells' 17:00:16 o/ 17:00:54 o/ 17:00:56 ohai 17:01:03 welcome mriedem 17:01:06 #topic bugs 17:01:21 mriedem: you had a couple in the last week or so right? 17:01:23 there is a backport proposed for the guest assisted snapshot one 17:01:33 https://review.openstack.org/#/c/498979/ 17:01:37 cool 17:01:58 i think that's the only cells v2 bug recently, everything else is placement 17:02:03 okay cool 17:02:11 anything else on bugs? 17:02:15 do'nt think so 17:02:23 #topic open reviews 17:02:56 I don't have anything for this at the moment either, since I'm working on some placement things we need to get done ASAP 17:03:16 i don't think there are any open reviews for cells v2 that i know of 17:03:16 anyone else? 17:03:22 ack 17:03:28 #topic open discussion 17:03:35 mriedem: you wanted to scheme about ptg things right? 17:03:38 yes 17:03:42 https://etherpad.openstack.org/p/nova-ptg-queens 17:03:56 there are some random things 17:03:58 I've put a few things on there so far for cells 17:04:22 the main things i think are 17:04:25 1. Use GET /usages from the Placement API for counting quotas rather than iterating cells. 17:04:33 2. Scheduling alternative hosts in the cell for retries 17:04:43 edleafe has a spec related to ^ 17:04:57 https://review.openstack.org/#/c/498830/ 17:04:59 yep, I took a first pass on that spec, 17:05:14 although it's just a piece of the puzzle 17:05:24 right it's not the full picture 17:05:33 just the data format i think between conductor and scheduler right? 17:05:39 yeah 17:05:59 3. all of the upcall stuff https://docs.openstack.org/nova/latest/user/cellsv2_layout.html#operations-requiring-upcalls 17:06:20 *all of the "other" upcall stuff 17:06:35 yeah I need to revisit those things and see what is actionable 17:06:40 on the GET /usages thing the missing piece will be counting instances independent of cells. and the need to keep instance mappings around forever because deleted instances. I was wondering if it would be kosher to add a deleted column to instance mappings to know whether to count 17:06:43 the affinity stuff just has to wait for the distance placement stuff 17:07:14 melwitt: if it's in placement we count it, and if it's not we don't right? 17:07:14 melwitt: knee jerk reaction is we don't want a deleted column on instance_mappings 17:07:19 yeah, do not want 17:07:32 does placement have instances count in it? 17:07:47 no, 17:08:01 i think that means, GET /allocations/{instance_uuid} returns 404 right? 17:08:11 right 17:08:25 and that would also tied into how GET /usages works when filtering on instance.project_id and instance.user_id 17:08:42 if the instance is deleted, it shouldn't be in the placement allocations table and it's usages won't be affected by the instance consumer 17:08:47 ohhh, I see what you're saying 17:09:06 we should be able to list allocations by project too, so you can get a list of all the instances for a given project/user and that will have consumer ids, which are instances 17:09:27 sweet. 17:09:45 that works for me 17:09:50 the counting via placement stuff is all a bit busted right now too with how we're accounting for allocations during a move 17:09:58 which is going to be fixed with dan's migration uuid stuff 17:10:06 yah 17:10:16 oh, right. so we won't get a double count for a move-in-progress 17:10:21 ? 17:10:35 well, 17:10:43 you won't if you consider only instances 17:10:58 but I think you'll want to consider migrations too so your quota covers things you have in resize_confirm state right? 17:11:48 maybe, now that it could potentially be consuming twice the resources, I wouldn't want that counting against quota 17:11:58 no? 17:12:09 we don't double account quota during a move today 17:12:12 I thought there was a request to prevent people from having 20 instances, all in resize_confirm state for a month 17:12:17 right, but that's a bug right? 17:12:19 we pike the bigger parts of the flavor and count that for quota 17:12:24 I didn't think so. well, it would be a regression or rather it will change how quota has been counted 17:12:31 *pick 17:12:33 because this double allocating thing is new right? 17:12:44 the double accounting is new 17:12:44 well, regardless, right now you can't tell the difference between the two halves of a migration, 17:12:59 and after my change, counting just the instance allocation will give you the target of the migration, which is what you want 17:13:14 whether or not we work in the source side is something we can discuss 17:13:27 okay 17:13:35 but because of the way I have it set up, it'll just do what you're expecting by default 17:13:51 so we can discuss at the ptg maybe and see what others think 17:14:02 k 17:14:07 pretty sure I was talking to johnthetubaguy about the migration quota limit thing, so if he's there we can get his input 17:14:21 i think we'd have to account for the source side 17:14:29 for an old flavor that has bigger cpu/ram than the new flavor 17:14:45 otherwise if you resize, then do something else to raise quota, and revert, you could go over quota on the revert 17:15:16 but yeah i suppose details can be hashed out at the ptg 17:15:49 I think that's confusing and not what _I_ would want, but yeah, we can argue later 17:15:54 yeah. I suspect you're right though. currently we're considering old flavor or new flavor depending on whether it's an upsize or downsize 17:16:38 for multi-cell ci testing, 17:17:14 i think in boston sdague said he wanted to write some new deployment tooling using ansible or something since devstack/devstack-gate/grenade gets too complicated with all the bash and multiple nodes and such 17:17:36 but, that seems like a herculian task 17:17:38 yeah I'm not so sure how likely that is to happen at this point 17:17:39 yeah 17:18:06 but i think we should definitely try a 2-cell ci job in queens 17:18:25 well, I'd like to, but there are a lot of things piling up quickly so I don't want to put it too high on the priority list 17:18:26 so far, 17:18:44 I haven't found anything that works with our gate but doesn't with two real cells 17:19:01 I'm sure there are some, but seems like not too major 17:19:16 anyway, worth discussion at the ptg, which is what we're doing here 17:19:19 yeah it doesn't need to be top priority, but if we can at least figure out some of the high level what needs to happen, i know enough about d-g to do some damage 17:19:42 woot 17:20:02 the efficient listing stuff... 17:20:03 idk 17:20:35 I need to sync back up with mdbooth on that, but I'm hoping he's still going to do it.. last I heard from him it sounded like he was, 17:20:43 but if he's not we have to get a plan for that I think 17:21:02 I'm willing to pick it up if he can't get to it 17:22:04 mriedem: what else? 17:22:45 i see melwitt added consoles 17:22:48 I'll be continuing the consoles stuff. there's some review on it that I need to address 17:23:51 re-propose the spec if you haven't already 17:24:18 yeah, will do that 17:24:40 I probably need a new spec for swapping the quota count with placement calls too 17:24:47 do you think? 17:24:58 yeah 17:25:18 yes 17:25:46 okay. what about for the DB magic instance listing? 17:26:04 that's purely poc at this point i think 17:26:28 so finish the patch and then write a spec? 17:26:35 if it works 17:26:37 not sure it requires a spec 17:26:46 it should be transparent to the user 17:26:52 oksy 17:26:55 *okay 17:26:56 what magic instance thing? 17:26:57 it's really fixing a bug 17:27:03 mdbooth's thing 17:27:14 oh listing 17:27:18 * dansmith read that wrong 17:27:52 well i think that's probably certainly enough crap to worry about 17:28:02 agreed 17:28:14 cool, so anything else? 17:28:18 no 17:28:23 nay 17:28:28 awesome 17:28:32 #endmeeting