Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-19
16:04:30 mriedem cdent: just once, join evil corp
16:04:30 melwitt "we fixed the glitch"
16:04:59 mriedem bauzas: dansmith: jaypipes: i left a summary in the spec
16:05:02 mriedem https://review.openstack.org/#/c/437424/
16:05:06 cdent mriedem: I'm not sure I have any soul left to sell
16:05:11 jaypipes mriedem: danke
16:05:34 mriedem at a high level i feel like we should be accounting for the overhead (real usage) in the allocations
16:05:52 mriedem which would also benefit the initial select_destinations since placement has the whole story for actual allocations on a provider
16:05:59 hypothermic_cat lyarwood: hi, are you around?
16:06:44 lyarwood hypothermic_cat: hey, what's up?
16:06:51 mriedem i agree that over-estimating the reserved inventory buffer is an easier solution on us, but it also means operators have to be taking that into consideration now when configuring the comptues and doing capacity planning
16:07:11 cdent only if we don't automate it (through magic yet to be determined)
16:07:14 dansmith mriedem: unless we inflate the reserved amount ourselves
16:07:15 dansmith right
16:07:27 mriedem yeah i don't know how we do that yet
16:07:50 bauzas mriedem: okay, will read it
16:07:52 mriedem this is definitely fodder for the forum session on claims in the scheduler
16:07:56 bauzas and will try to make a new rev soon-ish
16:07:58 melwitt I don't remember what the "overhead" is. I've seen it before in the RT
16:08:10 mriedem melwitt: see estimate_instance_overhead in the virt drivers
16:08:19 melwitt or the virt driver
16:08:43 bauzas melwitt: don't put your foot into that ... :p
16:08:55 mriedem it's related to quota so melwitt has to put both feet in
16:08:56 melwitt I have before but then I forgot, so I guess I'm safe
16:08:58 bauzas or take the left one, if you want to be lucky
16:09:12 dansmith mind the boots
16:09:18 mriedem i was going to say,
16:09:26 mriedem it would have to be deep to get up over the boots
16:09:38 melwitt hah, yeah. feet protection
16:09:57 bauzas I should consider that for myself
16:10:00 hypothermic_cat lyarwood: I split the dteach patch into a zillion small ones: https://review.openstack.org/#/q/topic:bp/cinder-new-attach-apis
16:10:12 melwitt it feels weird to think of taking up more quota usage than the flavor says though
16:10:27 bauzas yup
16:10:38 bauzas and it would expose the hypervisor usage to the users, nope ?
16:10:40 melwitt so I don't think I would be for that
16:10:47 bauzas melwitt: +1
16:10:49 hypothermic_cat lyarwood: and I remember you asked about it earlier and was wondering whether you have bandwidth to look into any of those :)
16:11:10 bauzas I think we should not impact the quota usage by that, or it would expose some internal consumption logic for the end-user, nope ?
16:11:41 bauzas if I was nasty, I'd guess which host I'm in if I'm able to see my quota decrease differently
16:11:43 bauzas at leasy
16:11:44 dansmith if we increase our allocations, that's how it would manifest
16:11:55 dansmith which is another reason why hiding it in reserved is better
16:11:57 dansmith IMHO
16:12:00 lyarwood hypothermic_cat: I will tomorrow morning, I've been stuck downstream all week but I'll make time to reviews these in the morning. mdbooth, johnthetubaguy & mriedem ^ might also want to look at these prior to the meeting tomorrow.
16:12:07 openstackgerrit Mikhail Feoktistov proposed openstack/nova master: Remove fstype param from ploop init https://review.openstack.org/444970
16:12:12 bauzas dansmith: maybe
16:12:19 bauzas if we try to merge quotas with placement
16:12:25 dansmith bauzas: we're doing that
16:12:32 bauzas I know
16:12:36 bauzas speaking out loud
16:12:53 hypothermic_cat lyarwood: additional tests are on their way for the base detach changes
16:13:17 mriedem dansmith: bauzas: melwitt: ok i didn't think about that part, so reply in the spec i suppose
16:13:30 bauzas dansmith: FWIW I tried to advocate way earlier this morning that I'm in favor of decrementing the total left amount than fixing the allocation
16:13:40 hypothermic_cat lyarwood: I'm stuck a bit too this week, I need to find more people, who could look into the code :)
16:14:25 bauzas dansmith: unrelated, I have a couple of comments on your cells-aware series
16:14:40 bauzas both can be me being wrong
16:16:15 rfolco cdent, quick question: I am doing a cleanup on inventory.py replacing http error msg from db api with specific messages, like here: https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/inventory.py#L409 - should we do this for other cases like BadRequest ?
16:17:03 dansmith bauzas: one is why my devstack patch is failing :D
16:17:18 bauzas I'M NOT WRONG, WOOOOT!
16:18:10 cdent rfolco: just a sec, catching up
16:18:10 dansmith bauzas: no, you're still wrong
16:18:20 dansmith no t-shirt for you
16:19:03 bauzas dansmith: L71 ?
16:19:07 bauzas how come ?
16:19:21 dansmith bauzas: no, L71.5
16:19:31 rfolco cdent, more context: would be an extension of https://review.openstack.org/#/c/436773
16:19:51 bauzas dansmith: excuse my ignorance, but what is L71.5 ?
16:19:54 cdent rfolco: yeah, the general idea is to not expose the database error in the exception message, throughout the placement service
16:20:08 dansmith bauzas: the line between 71 and 72
16:20:25 cdent rfolco: sometimes the exception message will already be good, other times not. it depends on the exception that's coming from the object level: it's inconsistent
16:20:35 bauzas like the platform 9 3/4 ?
16:20:49 melwitt yeeeah
16:20:49 cdent rfolco: in general the goal is to make the message that the end user sees less annoying, so use that as your guide
16:21:06 cdent rfolco: but unfortunately I need to go, house guests just showed up...
16:21:07 dansmith bauzas: I don't get that reference, but.. probably?
16:21:18 rfolco cdent, that helped. Thanks.
16:21:42 melwitt dansmith: you don't know ... harry potter??
16:21:48 cdent rfolco: add me to the review(s) when stuff's ready please, so I can be sure to look at them and also to add them to the weekly email
16:21:55 dansmith melwitt: never seen it
16:22:01 melwitt omg
16:22:14 bauzas melwitt: seriously, he doesn't loose a lot
16:22:17 dansmith melwitt: well, I watched five minutes of it, and couldn't handle it
16:22:35 dansmith LOTR and harry potter, I just can't stomach
16:22:49 bauzas dansmith: dammit, the platform 9 3/4 was shown at 10 mins after the beginning
16:22:58 dansmith oh well :)
16:24:10 bauzas either way, I have to change my glasses this week
16:24:23 bauzas so probably I'll review better
16:25:56 dansmith bauzas: in my defense, the tests did add a cell, but I neglected to create the instance in the new cell, so .. I intended to have coverage to prove I was doing the right thing, I just failed.. twice
16:35:52 openstackgerrit melanie witt proposed openstack/nova master: Mock timeout in test__get_node_console_with_reset_wait_timeout https://review.openstack.org/458161
16:37:32 mriedem dansmith: is this for the server groups thing?
16:37:41 dansmith yeah
16:38:13 mriedem could just write a functional test instead,
16:38:21 mriedem i'm finding that's easier with some of the api driven stuff and multi-cell
16:38:43 dansmith mriedem: this one is basically functional.. uses the actual db
16:38:57 dansmith mriedem: it didn't catch it because I made the same mistake in the test as the code
16:45:10 melwitt mriedem: I wonder if there's a bug in the backoff looping timer, it doesn't make sense that it wouldn't time out at all
16:45:34 melwitt it's supposed to end early if the backoff would put it over the specified timeout
16:46:14 openstackgerrit Dan Smith proposed openstack/nova master: Make server groups api aware of multiple cells for membership https://review.openstack.org/457338
16:46:15 openstackgerrit Dan Smith proposed openstack/nova master: Sort CellMappingList.get_all() for safety https://review.openstack.org/443174
16:46:15 openstackgerrit Dan Smith proposed openstack/nova master: Clean up ClientRouter debt https://review.openstack.org/444487

Earlier   Later